fix(Mountain): Return Cocoon PID for debug adapter and register walkthrough commands

Two related changes to improve extension host integration:

1. **Cocoon PID for debug adapters** (`WindServiceHandlers/mod.rs`, `CocoonManagement.rs`): The `extensionHostStarter:start` IPC handler was incorrectly returning Mountain's own PID. The renderer uses this PID to correlate extension-host-side debug adapters with the actual Node.js process. Now we return the Cocoon child process PID via a new `GetCocoonPid()` function that reads from an atomic static, avoiding the need to take the async `COCOON_STATE` mutex.

2. **Walkthrough command no-ops** (`Bootstrap.rs`): The `claude-code` extension invokes `workbench.action.openWalkthrough` and `claude-vscode.openWalkthrough` at activation. Land has no walkthrough/welcome UI yet. Register both commands as native no-ops that return `null` to prevent "command not found" errors during extension activation.

Impact: Debug adapters now attach to the correct Node.js process (Cocoon), and the claude-code extension activates without errors.

Author: NikolaRHristov

Source/Command/Bootstrap.rs

@@ -352,6 +352,26 @@ fn CommandSetContext(
 	})
 }
 
+/// Native no-op for `workbench.action.openWalkthrough`. VS Code's
+/// walkthrough UI lives in `workbench/contrib/welcomeGettingStarted` and is
+/// not wired through Land yet. Extensions (notably `claude-code`) invoke this
+/// at activation - returning null avoids a user-visible "command not found"
+/// error while the walkthrough system remains unimplemented.
+fn CommandOpenWalkthrough(
+	_ApplicationHandle:AppHandle<Wry>,
+
+	_Window:WebviewWindow<Wry>,
+
+	_RunTime:Arc<ApplicationRunTime>,
+
+	Argument:Value,
+) -> Pin<Box<dyn Future<Output = Result<Value, String>> + Send>> {
+	Box::pin(async move {
+		dev_log!("commands", "[Native Command] openWalkthrough (no-op): {}", Argument);
+		Ok(Value::Null)
+	})
+}
+
 /// A native command for reloading the window.
 fn CommandReloadWindow(
 	_ApplicationHandle:AppHandle<Wry>,
@@ -516,6 +536,20 @@ pub fn RegisterNativeCommands(
 	CommandRegistry.insert("vscode.open".to_string(), CommandHandler::Native(CommandVscodeOpen));
 	CommandRegistry.insert("vscode.openFolder".to_string(), CommandHandler::Native(CommandVscodeOpen));
 
+	// `workbench.action.openWalkthrough` is VS Code's welcome/getting-started
+	// walkthrough entry point; the `claude-code` extension wraps it with its
+	// own `claude-vscode.openWalkthrough` command and invokes both at
+	// activation. Land has no walkthrough UI yet - register both as no-ops so
+	// extension activation doesn't surface "command not found" errors.
+	CommandRegistry.insert(
+		"workbench.action.openWalkthrough".to_string(),
+		CommandHandler::Native(CommandOpenWalkthrough),
+	);
+	CommandRegistry.insert(
+		"claude-vscode.openWalkthrough".to_string(),
+		CommandHandler::Native(CommandOpenWalkthrough),
+	);
+
 	dev_log!("commands", "[Bootstrap] {} native commands registered.", CommandRegistry.len());
 
 	drop(CommandRegistry);

Source/IPC/WindServiceHandlers/mod.rs

@@ -1458,8 +1458,16 @@ pub async fn mountain_ipc_invoke(app_handle:AppHandle, command:String, args:Vec<
 					Ok(json!({ "id": "1" }))
 				},
 				"extensionHostStarter:start" => {
-					dev_log!("exthost", "extensionHostStarter:start pid={}", std::process::id());
-					Ok(json!({ "pid": std::process::id() }))
+					// The renderer uses this PID to correlate extension-host-side
+					// debug adapters with the actual Node.js process. That process
+					// is Cocoon, not Mountain - returning `std::process::id()`
+					// here would point the debugger at Mountain's Rust binary.
+					// Fall back to Mountain's PID only if Cocoon hasn't spawned
+					// yet (should not happen for a real extension-host start).
+					let Pid = crate::ProcessManagement::CocoonManagement::GetCocoonPid()
+						.unwrap_or_else(std::process::id);
+					dev_log!("exthost", "extensionHostStarter:start pid={}", Pid);
+					Ok(json!({ "pid": Pid }))
 				},
 				"extensionHostStarter:kill" => {
 					dev_log!("exthost", "extensionHostStarter:kill");

Source/ProcessManagement/CocoonManagement.rs

@@ -121,6 +121,21 @@ lazy_static::lazy_static! {
 		Arc::new(Mutex::new(HealthMonitor::new()));
 }
 
+/// Last-known PID of the Cocoon child process. Mirrored here so callers can
+/// read it without taking the async `COCOON_STATE` mutex (e.g. from IPC
+/// handlers such as `extensionHostStarter:start`). Set after spawn and
+/// cleared on shutdown. `0` means "not running".
+static COCOON_PID:std::sync::atomic::AtomicU32 = std::sync::atomic::AtomicU32::new(0);
+
+/// Return the Cocoon child process's OS PID, or `None` if Cocoon has not
+/// been spawned (or has exited).
+pub fn GetCocoonPid() -> Option<u32> {
+	match COCOON_PID.load(std::sync::atomic::Ordering::Relaxed) {
+		0 => None,
+		Pid => Some(Pid),
+	}
+}
+
 /// The main entry point for initializing the Cocoon sidecar process manager.
 ///
 /// This orchestrates the complete initialization sequence including:
@@ -341,6 +356,7 @@ async fn LaunchAndManageCocoonSideCar(
 	})?;
 
 	let ProcessId = ChildProcess.id().unwrap_or(0);
+	COCOON_PID.store(ProcessId, std::sync::atomic::Ordering::Relaxed);
 	dev_log!("cocoon", "[CocoonManagement] Cocoon process spawned [PID: {}]", ProcessId);
 	crate::dev_log!("cocoon", "spawned PID={}", ProcessId);
 
@@ -571,6 +587,7 @@ async fn monitor_cocoon_health_task(state:Arc<Mutex<CocoonProcessState>>) {
 					// Update state
 					state_guard.IsRunning = false;
 					state_guard.ChildProcess = None;
+					COCOON_PID.store(0, std::sync::atomic::Ordering::Relaxed);
 
 					// Report health issue
 					{