fix(cli,web): hide Windows spawn windows and show queued attachments

[junxin367]

Summary

• Show queued message attachments as inline filename chips so image/file context follows the queued prompt.
• Hide transient Windows child process windows for runner-spawned sessions and related CLI probes.
• Add regression coverage for queued attachment previews and Windows hidden-spawn options.

Why

• Queued prompts with images looked like the attachment was still attached to the composer, which could make users think the next prompt would reuse it.
• On Windows, web-triggered new sessions could briefly open multiple pwsh/cmd windows before closing.

Scope / impact

• Web: queued messages now keep text and attachment filenames together in the queued bar.
• CLI: child processes launched through common spawn paths set windowsHide on Windows.
• No protocol or storage migration changes.

Validation

• bun vitest run src/utils/spawnWithAbort.test.ts src/agent/backends/acp/AcpSdkBackend.test.ts src/utils/spawnHappyCLI.test.ts src/codex/utils/codexExecutable.test.ts src/claude/sdk/utils.test.ts src/codex/utils/codexVersion.test.ts - 6 files, 63 tests passed.
• bun run --cwd web test QueuedMessagesBar.test.tsx - 1 file, 17 tests passed.
• bun run --cwd cli tsc --noEmit - passed.
• bun run --cwd web typecheck - passed.
• git diff --check - passed.

Risk / rollback

• Low risk. Changes are limited to UI rendering for queued attachments and Windows spawn options.
• Roll back this commit if hidden process spawning causes agent launch issues on Windows.

Reviewer notes

• Please focus on whether every web-triggered Windows spawn path that can create a transient shell now uses windowsHide.
• The queued attachment UI intentionally shows filename chips, not full previews, to keep the floating bar compact.

[github-actions]

Findings

• [Minor] Editing an attachment-only queued item now drops all visible context. getQueuedMessagePreview returns text: '' for attachment-only messages, but handleEdit still cancels the queued message first and only restores text into the composer. Before this split, attachment-only rows at least reused the filename string as the edit fallback; now clicking Edit on a queued image/file leaves the composer blank after the queued message is removed. Evidence: web/src/components/AssistantChat/QueuedMessagesBar.tsx:201
  Suggested fix:

  const { text, attachmentNames } = getQueuedMessagePreview(msg)
  const editText = text || attachmentNames.join(', ')
  
  // inside onSuccess
  if (editText) {
      assistantApi.composer().setText(editText)
  }
  onEdit?.({ text: editText, pendingSchedule: restoredPendingSchedule })

Summary
Review mode: initial
One minor regression found in the queued attachment UI. The Windows spawn changes look scoped; residual risk is Windows-only behavior that I could not execute in this environment.

Testing

• Not run (automation): bun is not installed in this runner (/bin/bash: bun: command not found).

HAPI Bot

[github-actions]

Findings
No findings.

Summary
Review mode: follow-up after new commits
No issues found in the latest full diff. The follow-up commit addresses the previous attachment-only queued edit regression with an edit-text fallback and unit coverage. Residual risk: Windows-only process-window behavior was not executable in this Linux runner.

Testing

• Not run (automation): bun is not installed in this runner (/bin/bash: bun: command not found).
• git diff --check passed for the changed files.

HAPI Bot