Show the CMake sidebar immediately with an initializing placeholder during activation

[Hannia Valera (hanniavalera)]

What

The CMake Tools activity-bar sidebar, the container icon and all of its views (Project Status, Project Outline, Pinned Commands, Bookmarks), was hidden until the extension finished initializing. On machines where process/file I/O is intermittently slow, that can take minutes, during which the sidebar simply does not appear.

This PR introduces a two-phase reveal: the CMake activity-bar container now appears immediately with a lightweight, inert "CMake Tools is initializing…" placeholder, and hands off to the real views as soon as the backend is ready.

Why

The container and every view are gated on the cmake:enableFullFeatureSet context key, which the extension only sets to true at the very end of ExtensionManager.init() — behind a serial chain of subprocess probes (cmake --version / -E capabilities, the kit file read, preset parse/expansion, and the Visual Studio developer-environment bootstrap (vcvarsall) for cl.exe presets).

When the environment makes process creation and file reads intermittently slow — e.g. antivirus scanning of every spawned executable, or extension-host file-handle exhaustion (EMFILE) — those probes serialize into minutes of wall-clock time, and the entire sidebar stays hidden the whole time. cmake:enableFullFeatureSet also gates ~255 other contributions (commands, menus, keybindings, the status bar), so it cannot simply be flipped early without exposing project actions against a not-yet-initialized backend.

How

• A new cmake:isInitializing context key backs a transient, inert placeholder view (cmake.initializing) whose content comes from viewsWelcome. The activity-bar container's when becomes cmake:isInitializing || cmake:enableFullFeatureSet, and the placeholder view is gated on cmake:isInitializing && !cmake:enableFullFeatureSet.
• The real views, commands, menus, and status bar remain gated exclusively on cmake:enableFullFeatureSet — nothing runs against a partially-initialized project. The transient placeholder and the real views are mutually exclusive, so there is no double-render and no empty-container flicker during the handoff.
• cmake:isInitializing is set right after the manager is constructed (via setContextValue, so it does not trigger a command recompute) and cleared in a finally after activation settles, so the placeholder can never get stuck on failure or when no project is found.
• The placeholder is shown only when a cheap, fail-open preflight determines the workspace has a CMake project: it does variable expansion plus a single CMakeLists.txt stat per configured source directory (mirroring hasCMakeLists()), with no subprocess spawn, kit/preset init, or recursive scan. Crucially it fails open — only ENOENT/ENOTDIR count as "no project"; transient errors like EMFILE still show the placeholder, so the fix works in exactly the resource-starved environments it targets. It is skipped entirely in language-server-only mode.

Scope

This is a UI-reveal fix. It does not change the actual initialization work, its ordering, or timing, the environmental slowness itself (antivirus, EMFILE) is outside the extension's control. Deferring the individual probes (VS developer-environment acquisition, language-service asset loading) is a worthwhile but separate, higher-risk follow-up

Testing

• yarn backendTests (386 passing) — new activation.test.ts (visibility policy + fail-open filesystem-error classification, incl. EMFILE) and activation-contributions.test.ts (container/view when gating, the "placeholder and real views are never simultaneously visible" invariant, and that cmake:isInitializing never gates any command/menu/keybinding).
• yarn unitTests, 330 passing.
• tsc + gulp lint clean.
• Behavior verified unchanged in presets and kits/variants modes, single- and multi-config generators, multi-root, language-server-only mode, configure-on-open on/off, and non-CMake / standalone .cmake workspaces (no placeholder shown).