docs(0182): record route (c), and settle the snapshot count at two

[karczuRF]

Summary

The completion order agreed for the repair chain already settled this — 0201 → 0182 → 0172 close, sequenced — but the task file still listed routes a/b/c as undecided under "⛔ This now blocks the run … nothing below can be scheduled until it is settled". A fresh session reads the task file, not the session note, so on paper the run was still blocked. This closes that gap.

• Route (c) recorded as decided, with why it beat (a) and (b): a combined run swamps the rows_reset ≈ rows_enriched check ~32M against ~357k, and that check is the only signal that catches values zeroed and never recomputed — the worst outcome this task can produce. Route (b) is the better tool but costs a PR before any prod run and leaves 0201 outstanding anyway.
• What each pass actually runs: pass 1 = 0201, coarse-repair without --reset-*, draining the ~32M fillable pre-Soroban zeros until the table is at its floor; pass 2 = 0182, with --reset-quote-asset-id 111 --reset-not-before 1612656000, at which point rows_reset ≈ rows_enriched is meaningful again. Also notes this keeps the "run reset mode once per table" rule intact, since pass 1 is not a reset invocation.
• FREEZE span pinned at 67 months × 5 tables, which is what the admin needs in order to take the snapshot.
• Checkboxes, the "remaining, in order" list and the acceptance criterion all updated to match; ⛔ markers removed from the mechanism item only.

Still blocking the run (unchanged by this PR)

• A ClickHouse admin must take the FREEZE — prices_writer cannot and cannot be granted it.
• ⛔ One operational question left open deliberately, for the operator to settle with the admin: one snapshot before pass 1, or two (a second between the passes). One is cheaper; rolling pass 2 back then also discards pass 1's ~32M recovered rows. Two makes the passes independently revertible.

Note: 0201 is the operator's own task — this records the sequencing only, it does not claim or start that work.

---

Added 2026-08-18 — the snapshot count, settled at two

The one operational question this PR originally left open ("one snapshot or
two") is now answered: two, so pass 2 is revertible without discarding pass
1's ~32M recovered rows. Three things follow that the decision does not state on
its own.

• The names must differ. The freeze script's already-frozen branch keeps a
  pre-existing snapshot rather than overwriting it — correct behaviour, but it
  makes a second freeze under the same name a silent no-op: it reports
  success while leaving you one rollback point. repair_0182_pre_… then
  repair_0182_mid_….
• It rules out interleaving the passes per table. The second snapshot sits
  between the passes, so a per-table interleave needs the admin back five times
  across 10-15 h — and prices_writer cannot FREEZE. Ordering is now the
  hybrid: _1h alone as the review gate, then the other four batched. Three
  admin windows, tabled in the task file.
• Disk, measured on prod rather than estimated. 16.82 GiB in span across the
  five tables (799 active parts), _1h alone 9.56 GiB. A FREEZE hardlinks, so
  it costs nothing when taken; the cost accrues as the run's version + 1
  inserts merge and supersede the pinned parts, ceilinged at what was frozen.
  Both snapshots peak at ~33.6 GiB plus ~4-6 GiB of new parts — ~9% of the 430.6
  GiB free, though a ~68% increase on our own 58.93 GiB footprint.

Also adds a cleanup section and an acceptance criterion for it. Nothing
expires a snapshot, and neither ClickHouse nor the tool removes one, so ~33.6
GiB stays pinned on a volume BE own 96% of until an admin unfreezes it — the
same shape as the incident this whole chain started from.

Still no FREEZE taken and no partition written.