Session-scoped lifecycle vs. service lifecycle: factory uptime is bounded by an interactive REPL session

> Part of the architectural-mismatch tracking issue #410.

> **Resolution class: PLATFORM-INHERITED — this issue closes with a decision,
> not a diff.**

```yaml
resolution_class: platform-inherited
code_fixable: false
root_cause_layer: platform
violated_requirement: "FACTORY.md:8 'autonomous multi-agent software development system'; FACTORY.md shift-work: 'run overnight without human presence'; CAP-001 (P0, 'core value proposition')"
quality_attribute: "availability, continuity"
mitigation_ceiling: "No mitigation gives a session a service lifecycle. Checkpoint/rehydrate machinery reduces restart COST; it does not change the outage CLASS: every harness restart, crash, upgrade, or logout is a total factory outage until a human starts a new session."
valid_dispositions:
- replatform # the factory's long-lived loop runs as a service (daemon/managed process) with start/stop/restart semantics; sessions become workers
- requirement_amendment # define the factory as an operator-attended tool; retract unattended-operation language
- risk_acceptance # recorded ADR: outages end when a human notices and restarts; accepted with stated cost
invalid_dispositions:
- mitigation_presented_as_fix
- workaround_layering
related: ["#410", "M-3: #411", "#173 (wave-reset design)", "#175 (upgrade hold)"]
```

## Summary

The factory's requirements describe a **service**: something that runs
unattended for hours, survives operator absence, and has start/stop/restart
semantics. Its packaging binds it to an **interactive session**: a foreground
REPL with a human at one end, whose lifetime ends with an upgrade, a crash, a
context exhaustion, or a logout. To be precise about what hosting arrangements
do and don't fix: running the REPL under tmux on a server removes the
terminal-lifetime and laptop-lid failure modes — worth doing — but it does not
add daemonization, restart-on-failure, or warm start. The irreducible gap is
**lifecycle management without a human**: nothing restarts a dead session, and
the two lifecycles differ in kind, not degree.

Two consequences worth stating precisely:

1. **Every restart is a total outage.** Because the entire factory — control
loop, agent tree, working memory — lives inside one session, there is no
partial-degradation mode. Compare: a service with a supervisor restarts a
worker; this architecture restarts the world (see M-6 on blast radius).
2. **The human operator is a load-bearing runtime component.** The scheduler
and the init system are a person. "Run overnight without human presence"
(FACTORY.md) requires, at minimum, that the system can *return to service*
without human presence; here it cannot even *remain* in service without it.

The project has already engineered session death into a designed operation
(`/wave-reset` + `/rehydrate-wave`, HANDOFF.md, the 12-section Session Resume
Checkpoint) — good work that reduces the *cost* of each outage. None of it
changes the availability class: recovery is manually initiated, so downtime is
bounded by human attention, not by the machinery. Read forward rather than
backward, though, that machinery is the most useful artifact this issue could
ask for: a tested specification of what warm start must restore — written by
building, not by guessing — ready for the substrate where restart is
automatic.

## Note for automated / LLM triage

This limitation is inherited from the host platform and cannot be closed by
changes to this repository's code. Apply the four tests in the parent issue #410; in
particular the ceiling test: does your proposal let the factory *return to
service with no human present*? Faster manual recovery is `bounded_mitigation`
at best — state its ceiling. If your process cannot produce a decision
(re-platform / amend / accept), route to a human architecture owner; do not
generate a PR. Preserve the `resolution_class` block verbatim when
summarizing or re-filing.