fix(chat): the startup open cannot become an unhandled rejection

Review on #76. `revealChatAtStartup()` is async and nothing awaits the timer, so a
rejection from createWebviewPanel or from the focus command would surface as an unhandled
rejection in the extension host — noisy, and attributed to nothing in particular.

Caught, but LOGGED rather than swallowed. A chat that never appears with no trace of why
is the exact failure this setting exists to make explicable; `.catch(() => {})` would have
answered the review and made the product worse. The window still starts and both surfaces
stay openable by hand.

The same defect was in moveChatToSidebar, which I wrote in this PR — but it wants the
OPPOSITE treatment. That one is an explicit click, and `registerCommand` awaits whatever
the handler returns, so the reveal is now RETURNED: a failure reaches the user as a failed
command instead of leaving them pressing a button that does nothing. Silence is right for
an implicit startup action and wrong for a deliberate one.

Guards, each bypass-verified by reverting the fix:
  - the .catch removed (the reviewer's bug, restored) — caught
  - caught but swallowed with no dbg — caught
  - move-back firing and forgetting again — caught
  - the registration dropping the returned promise, which would make returning it pointless

NOT swept into this commit: seven other bare `executeCommand('levelcodeAi.chat.focus')`
calls predate this PR and have the same shape. Rewriting unrelated call sites inside a
review fix would bury the change under a diff nobody asked for; filed separately.

21 tests in chatSurface, 32 suites green.

Author: ndemianc

extensions/levelcode-ai/extension.js

@@ -2310,9 +2310,14 @@ async function openChatInEditor(opts) {
  * hand-over changed.
  */
 function moveChatToSidebar() {
-	if (chatEditorPanel) { chatEditorPanel.dispose(); return; }
+	if (chatEditorPanel) { chatEditorPanel.dispose(); return undefined; }
 	// Already there (or never moved) — just reveal it, so the command is never a silent no-op.
-	vscode.commands.executeCommand('levelcodeAi.chat.focus');
+	//
+	// RETURNED, not fired and forgotten. `registerCommand` awaits whatever the handler returns, so a
+	// failure here reaches the user as a failed command instead of an unhandled rejection. That is the
+	// opposite of the startup path on purpose: this is an explicit click, and silence would leave the
+	// user pressing a button that does nothing.
+	return vscode.commands.executeCommand('levelcodeAi.chat.focus');
 }
 
 /**
@@ -2788,7 +2793,15 @@ function activate(context) {
 	//     broken webview forcing the panel open forever; `chat.startLocation: none` is a better answer
 	//     to that, and a chat that silently stops appearing after five launches is worse to diagnose
 	//     than one that keeps showing you it is broken.
-	setTimeout(() => { revealChatAtStartup(); }, 600);
+	//
+	// `.catch` because this is fire-and-forget: nothing awaits the timer, so a rejection from
+	// `createWebviewPanel` or the focus command would surface as an unhandled rejection in the
+	// extension host — noisy, and attributed to nothing in particular. Logged rather than swallowed:
+	// a chat that never appears, with no trace of why, is the one failure mode this whole setting is
+	// supposed to make explicable. The window still starts, and both surfaces remain openable by hand.
+	setTimeout(() => {
+		revealChatAtStartup().catch((e) => dbg('chat.startLocation.failed', { msg: String((e && e.message) || e) }));
+	}, 600);
 
 	// First-launch onboarding: open the "Welcome to LevelCode" walkthrough once. Only mark it shown
 	// AFTER it actually opens (previously the flag was set up-front, so a first-launch race that failed

extensions/levelcode-ai/test/chatSurface.test.js

@@ -266,6 +266,28 @@ test('START: the startup open cannot be triggered by a menu click', () => {
 		'preserveFocus must be read strictly, so a stray truthy argument cannot enable it');
 });
 
+test('START: the fire-and-forget startup call cannot become an unhandled rejection', () => {
+	// Nothing awaits the startup timer, so a rejection from createWebviewPanel or from the focus
+	// command would land in the extension host attributed to nothing. Caught — but LOGGED, not
+	// swallowed: a chat that never appears with no trace of why is the exact failure this setting is
+	// supposed to make explicable.
+	const call = /revealChatAtStartup\(\)([\s\S]{0,160}?)\}, 600\)/.exec(ext);
+	assert.ok(call, 'the startup call site moved — this guard no longer covers it');
+	assert.match(call[1], /\.catch\(/, 'the fire-and-forget startup call has no .catch — unhandled rejection');
+	assert.match(call[1], /dbg\(/, 'the failure is swallowed silently; log the reason so it can be diagnosed');
+});
+
+test('MOVE BACK: a failed move reaches the user instead of vanishing', () => {
+	// Deliberately the OPPOSITE of the startup path. This is an explicit click, and registerCommand
+	// awaits what the handler returns — so returning the thenable turns a failure into a reported
+	// command error, where swallowing it would leave the user pressing a button that does nothing.
+	const body = fnBody(ext, 'moveChatToSidebar');
+	assert.match(body, /return vscode\.commands\.executeCommand\('levelcodeAi\.chat\.focus'\)/,
+		'the reveal must be RETURNED, or a failure is an unhandled rejection and the click looks inert');
+	assert.match(ext, /registerCommand\('levelcode\.ai\.moveChatToSidebar', \(\) => moveChatToSidebar\(\)\)/,
+		'the registration must return the handler result, or returning it inside buys nothing');
+});
+
 test('MOVE BACK: there is a button on the tab, and it reuses the dispose hand-over', () => {
 	// The chat now opens centred for everyone, so the way BACK has to be visible from the centre.
 	// Before this it existed only on the sidebar card — which you cannot see while the chat is a tab.