Fix startup commands frequently not running on launch (#14)

[frd1201]

Summary

Fixes #14 — per-pane startup commands frequently don't run when a workspace launches: intermittently for a single workspace, and almost always for the second workspace when two have launchOnStartup: true.

There are three independent timing/lifecycle root causes (full evidence in #14); this PR addresses all three.

Changes

1. Poll for panes instead of a single 300 ms shot — startupCommand.service.ts

onTabOpened() previously did setTimeout(() => processChildTabs(tab), 300) and called getAllTabs() exactly once. If the split panes weren't constructed yet at 300 ms, it found 0 tabs and every command for that workspace was silently skipped.

Now processChildTabs() re-scans the split on a short interval, processing panes as they appear, and stops once all of the split's pending commands are handled (or an attempt cap is hit).

2. Wait for real readiness before sending — startupCommand.service.ts

Commands were sent before the PTY session existed: the code blind-fired setTimeout(sendCommand, 500) into a shell that wasn't ready, so the input was dropped during shell init (clink/conpty in particular drop early input).

Now each command:

• polls until session.output$ actually exists, then
• waits for the shell prompt to render — output is ANSI-stripped and checked for a trailing prompt char (> / $ / # / % / ❯ / ➜), with an output-settle timeout and an overall hard cap as fallbacks.

3. Serialize startup launches — toolbar.provider.ts

When two launchOnStartup workspaces opened, only the active tab initialized its PTYs; the workspace that ended up in the background never got a session, so there was nothing to send to.

registerCommands() now returns a promise that resolves when the batch has been delivered (or a safety timeout elapses). openWorkspace() awaits it, so workspaces open one at a time — each stays foreground until its sessions connect and commands are sent before the next opens.

Notes

• Targets dev per CONTRIBUTING.md.
• All three changes have safety caps/timeouts so a single stuck pane can never block the remaining startup launches.
• Production build passes (npm run build), no new TypeScript errors.
• Reported measured impact of this approach in Startup commands frequently don't run on launch (panes processed before PTY session is ready; background workspace never connects) #14: ~11% → 100% pane delivery across cold starts on Windows (clink/cmd/PowerShell), including under load.

Follow-up (not in this PR)

#14 also notes a cleaner long-term option: pass the startup command via the shell's own launch args (cmd /k, pwsh -NoExit -Command, bash -c '…; exec bash') so the shell runs it itself, removing the typing-based timing heuristics entirely. Happy to explore that separately if preferred.