refactor(launch): aileron launch becomes a thin client of the daemon

[ALRubinger]

Summary

Step 8 of #454 — the structural change ADR-0012 has been building toward. This is the PR that fixes the original bug: aileron launch no longer re-prompts for vault unlock when a daemon is already running with an unlocked vault, because launch and CLI now share the daemon's vault.

Removed

• internal/launch/gateway.go and its tests — the per-session embedded gateway. The daemon owns the gateway now.
• internal/launch/vault_prompt_mode_test.go and the resolveVaultPromptMode / vaultPromptMode / vaultPathForGateway helpers. The daemon owns vault unlock; launch just observes status.
• generateSessionID — the daemon mints the ULID at POST /v1/sessions.

Added

• internal/launch/daemon_client.go — thin HTTP client for /v1/sessions, /v1/sessions/{id}/end, /v1/vault/local/status. ~150 lines.
• internal/launch/testmain_test.go — per-package httptest fake of the daemon, advertised via AILERON_API_URL. Tests don't need a real server binary on PATH.

Refactored

internal/launch/launcher.go:Launch is now:

1. spawn.Resolve to find/auto-spawn the daemon
2. POST /v1/sessions to register; daemon hands back the ULID
3. Set ANTHROPIC_BASE_URL, AILERON_URL, AILERON_APPROVAL_URL to the daemon URL (stable across launches)
4. Run the agent
5. POST /v1/sessions/{id}/end with the exit code (best-effort; the orphan-reaper handles the worst case)

printStartupBanner takes a daemonURL string instead of *Gateway. Vault-locked hint comes from a GET /v1/vault/local/status probe before exec — same banner shape, sourced differently.

composeAgentEnv stays (moved into launcher.go).

Binary lookup is skipped when AILERON_API_URL is set so spawn doesn't need a real server to fork-exec. (Same pattern as cmd/aileron from #472.)

Kept

• EnsureVault and PassphrasePrompter — the daemon binary (internal/server/main.go) still uses them for stderr-prompt unlock at startup. They're now internal to the daemon's setup, not used by launch.
• commsserver and approval socket — independent of the gateway. Step 9 (Umbrella: Local Daemon Architecture (ADR-0012) #454) moves them to daemon ownership.

Test plan

• go test ./internal/launch/... ./internal/app/... ./cmd/aileron/... -race is green.
• go vet ./... is clean.
• Existing TestLaunch_* tests all pass via the package-wide httptest fake daemon (sets AILERON_API_URL).
• printStartupBanner tests rewritten to take a string URL instead of *Gateway.
• Acceptance Tests 2 + 3 of Umbrella: Local Daemon Architecture (ADR-0012) #454 are the canonical proof: vault unlocks once, second launch reuses it. Verified end-to-end against the real daemon binary post-merge.

Notes

• The "first-run vault creation prompts on stderr" UX from Test 1 of the umbrella issue still depends on the daemon binary's selectVault path (which uses launch.EnsureVault). When launch fork-execs the daemon, the daemon is detached and can't prompt — first-run interactive setup remains a documented gap (deferred to a Step 7 follow-up).
• After this lands, aileron launch claude finally reuses the standalone daemon's unlocked vault. The bug we started this thread on is fixed.

🤖 Generated with Claude Code

[railway-app]

🚅 Deployed to the aileron-pr-476 environment in aileron

1 service not affected by this PR

• docs

[codecov]

Codecov Report

❌ Patch coverage is 76.69173% with 31 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.24%. Comparing base (7987efa) to head (2c95016).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #476   +/-   ##
=======================================
  Coverage   82.24%   82.24%           
=======================================
  Files         234      234           
  Lines       24127    24153   +26     
=======================================
+ Hits        19843    19865   +22     
+ Misses       3148     3144    -4     
- Partials     1136     1144    +8     

Flag	Coverage Δ
integration	8.40% <0.00%> (-0.05%)	⬇️
unit	78.90% <76.69%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.