Prototype B: raw async/await launch — no LifecycleKit at all

[kyleve]

Problem

This is a prototype for comparison, not a default-merge candidate — the last rung of the ladder: shipped combinators (#116) → context-driven functions (#117, the base of this PR) → no kit at all. The question it answers: what does the app look like when launch is nothing but raw async/await, and what is the engine actually earning?

Changes

Both kit targets are deleted (LifecycleKit, LifecycleKitUI, their test bundles and scheme entries; the host smoke tests move to StuffCoreTests). Launch is one raw async task per attempt:

// WhereLaunch.run — the whole engine is now this function's shape
let services = try await openServicesIfNeeded()     // still the one store open
let session  = model.startSession(services: services)
await onServicesReady(session.services)
await configureSessionIfHeadless()                  // service the wake NOW, then…
try await state.whenSceneActive()                   // ← promotion, as a PARK
if !model.hasOnboarded { try await onboarding(handle, session) }
state.publish(.ready(session))

• Promotion is a park, not a re-drive. The task awaits scene activation before its foreground tail, so a headless wake is serviced above the park and simply never proceeds. This dissolves whole categories of machinery: no LifecycleReason/buildsNoViewTree, no run-once memoization (nothing ever runs twice), no re-drive semantics. The one cost: an ordering the memo used to handle uniformly must now be branched explicitly (session configuration runs before the park when headless, after the onboarding park when the scene is already active — so a reset can't resume GPS into a freshly-erased store mid-re-onboarding).
• App-owned remnants in WhereUI (~230 lines total): WhereLaunchState (one Phase enum — launching | onboarding(handle, session) | failed | ready(session) — plus the scene signal and attempt/fan task ownership) and OnboardingHandle (the cancellation-aware, stale-safe resolution token). RootView absorbs the container's surface switching with the same zoom-reveal.
• No retry, by design (the discussion that motivated this prototype): the store-race that retry once caught was fixed structurally by injection in Fix fresh-install launch failure: canonical store, prompt promotion, honest splash #99/Typed LifecycleKit: compile-checked launch plans, engine/UI split, Where migration #116; launch failure is now terminal — logged, .failed, no button — and the recovery is relaunching the app. Reset keeps its safety semantics without retry: cancel + drain the attempt and its fan, erase, then a fresh attempt; a failed erase parks terminal with preferences intact.
• DetachedFailureReporter is deleted: the fan bodies are non-throwing session methods, so there is no failure channel left to mirror.

The three-way trade

	Combinators (#116)	Context functions (#117)	Raw async (this PR)
Swift LOC vs. previous rung	baseline	−412	−3,000 (net, incl. tests)
Ordering / use-before-produce	combinator constraints	plain data flow	plain data flow
Run-once across promotion	engine memo	engine memo	structural (park; nothing re-runs)
Retry	resume-at-node	re-run + memo (free)	none (terminal failure)
Invariants held by	engine, enforced	engine + one convention	conventions WhereLaunch documents (one store open, effects-vs-park placement, no phase writes from a cancelled attempt)
Reusability	any app	any app	Where-only (nothing left to reuse)
Engine test depth	320-seed fuzz + engine suites	same, ported	gone — Where-level behavior tests only

The honest summary: B is the leanest by far and the park model is genuinely elegant for this app's shape — but every guarantee became a convention, the seeded fuzz coverage died with the engine, and a second app (or a second gate, or resurrected retry) starts re-growing the kit by hand.

Testing

Where-level behavior tests with the scripted scene signal: a headless wake services tracking without passing the park (no capture, no .ready), activation resumes the tail, onboarding parks/resolves and its failure is terminal, onServicesReady re-fires on the reset relaunch, reset returns to onboarding over an empty store with preferences restored, and a reset while parked on onboarding drains the old attempt (its stale handle is a no-op). One accepted coverage loss vs. the base branch, named here: the reset-erase failure path (previously driven through the engine's failure-injection seam) is no longer unit-drivable — reset's catch is exercised only by reading. Full Stuff-iOS-Tests scheme green; ./swiftformat --lint clean.