fix(session): fail-fast (or warn loudly) when launcher dropped session key (#284.4)

[laulpogan]

Part 4 of #284 (Willard's Windows report).

Summary

When the launcher spawns wire without inheriting `WIRE_HOME` or `WIRE_SESSION_ID` (and no host-adapter env like `CLAUDE_CODE_SESSION_ID` either), the session adapter silently falls through to:

• `wire mcp` → mints a fresh per-process key (`SESSION_SOURCE = "minted"`).
• `wire daemon` / `wire monitor` / `wire notify` → runs against the machine-default identity (`SESSION_SOURCE = "machine-default"`).

Both fallbacks are usually not what the launcher meant. The operator only finds out minutes later when they notice a sibling process serving the real session-key home racing the inbox cursor with this one's machine-default-or-minted one. Willard's repro: the spawned shell dropped `WIRE_HOME` on the floor, the child wrote to the cwd-default home, and the resulting cross-home contention contributed to the `relay.lock` pileup behind #284.5.

Fix

A new helper `crate::session::warn_if_unexpected_session_source(role)`:

• Default: forces a clear stderr line naming the resolved source (`machine-default` / `minted`) and the operator-facing remediation ("pass an explicit `WIRE_SESSION_ID=` or `WIRE_HOME=`"). Force-rendered, not gated on TTY — these are spawn paths under Claude Code or scripts where stderr usually isn't a terminal.

• `WIRE_STRICT_SESSION=1`: upgrades the warning to a hard exit (code 2) at startup so the launcher fails-fast instead of letting downstream `init` / `bind` / `daemon` calls block on a shared relay-state lock or quietly write to the wrong home.

Each of the four inbox-owning entry points now calls `warn_if_unexpected_session_source` BEFORE `warn_on_identity_collision`:

Entry point	Call site
`wire mcp`	`mcp.rs`
`wire daemon`	`cli/relay.rs`
`wire monitor`	`cli/comms.rs`
`wire notify` (long-running, `--once`-excluded)	`cli/comms.rs`

The existing collision check stays in place; the session-source check is the earlier signal that catches the "launcher dropped the key" cases the collision check only fires for once a sibling process is also already running.

Pure-logic

`is_unexpected_session_source(&str) -> bool` is split out so the policy is exhaustively unit-testable across every adapter label.

Tests

3 new in `session::tests`, all green on `x86_64-pc-windows-msvc` (rustc 1.96.0):

• `is_unexpected_session_source_flags_machine_default_and_minted`
• `is_unexpected_session_source_passes_explicit_sources` — locks the policy against every existing adapter label (`env:WIRE_HOME`, `env:WIRE_HOME_FORCE`, `override`, `claude-code`, `claude-code-pidfile`, `codex-cli`, `copilot-cli`, `vscode-workspace`)
• `is_unexpected_session_source_handles_unknown_conservatively` — `unknown` (adoption never ran) doesn't get flagged; new adapter labels default to "explicit" until a maintainer opts them in.

Full lib suite: 489 passed; 0 failed; 7 ignored.

Stack

Stacks on top of #294 (Windows test/clippy hygiene). Sibling Windows-cluster PRs already open: #296 (#284.5), #297 (#247.4), #298 (#284.1), #300 (#284.2), #301 (#284.3). This rounds out the Willard #284 cluster + #247.4 from saffron's hand-off.

Test plan

• `cargo fmt --check` clean on Windows.
• `cargo clippy --all-targets -- -D warnings` clean on Windows.
• `cargo test --lib` 489/0/7 on Windows.
• CI green.
• Manual: run `wire daemon` from a shell with no `WIRE_HOME` / `WIRE_SESSION_ID` set, confirm the warning fires on stderr; re-run with `WIRE_STRICT_SESSION=1`, confirm exit code 2.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying wireup-landing with    Cloudflare Pages

Latest commit:	48da312
Status:	✅  Deploy successful!
Preview URL:	https://8b8a03f3.wireup-landing.pages.dev
Branch Preview URL:	https://fix-284-4-cli-wire-home-fail.wireup-landing.pages.dev

View logs