/archon-upgrade cannot produce a pre-adoption report — Step 1 compares floor, never latest

The defect

Measured on the command's first real proof run (2026-08-25, DXP-DesignSystem, plugin 0.24.2, Archon 0.7.0; full record relayed to #373's orchestrator): Step 1 branches on installed-vs-floor. Installed 0.7.0 == floor 0.7.0 → "no release range to assess", Steps 2–4 skip, only 5 and 6 run.

So the command is structurally silent in exactly the state a Consumer asks the question from: the CLI prints "Update available: v0.7.0 → v0.9.0" and the operator wants to know what adopting would mean before adopting. The command's own header ("run it after brew upgrade archon") is self-consistent — but classify-after-adoption inverts the decision the report exists to inform. #396 fixed Steps 5–6 being unreachable at floor; this is the remaining half.

The fix shape (from the run's own workaround)

Step 1 also compares installed against the latest released tag, and when floor < latest, runs Steps 2–4 over floor→latest as the pre-adoption report. The proof run executed exactly that by hand and produced a real table (ADOPT 3 · DEFER 1 · VERIFY-ONLY 9 · BREAKS-US 1), so the range-read works — only the branch withholds it.

Acceptance criteria

• Run at installed == floor with a newer release available: Steps 2–4 execute over floor→latest and the table is produced, pre-adoption.
• Run at installed == floor == latest: the command still reports "nothing to assess" and runs Steps 5–6 (the #396 behaviour is preserved).
• ADR-0035 is amended per the dated-blockquote convention.

Context

Related, same proof run: the probe-repeatability defect and the 0.9.0 MCP-inheritance BREAKS-US row (separate tickets); #422 (locate mechanism).

Start at the /archon-upgrade command's Step 1 branching logic and trace how it selects the installed, floor, and latest released versions. Verify that Steps 2–4 produce the floor→latest pre-adoption table when a newer release exists, while Steps 5–6 still run when installed equals the latest; then amend ADR-0035 using its dated-blockquote convention.