docs: start P1-RECOVERY and re-baseline its plan

[novelKR]

Requested by Seongjae · project thread

Before: the ledger records P1-RECOVERY as not-started, and its plan assumes CS-RG's C-series units and logical groups, which were never built. The integration specification's suspension notices still cover the recovery mode section, and ADR-001's current rule has no way for a Runner that outlives its Gateway to get the consumer credential.

After: the ledger records P1-RECOVERY as in-progress with a units ledger (P1R-C01 active), the plan carries a dated re-baseline on what exists, the recovery mode section is excepted from the suspension for P1-RECOVERY, and ADR-001 has a dated amendment for the independent Runner.

This is the ledger start for P1-RECOVERY, the same kind of change as #28 and #33 for CS-RG units. Tracker: novelKR/CodeSpace#101.

Why

On 2026-10-14 the owner directed P1-RECOVERY's implementation in CodeSpace as one pull request per unit, P1R-C01 to P1R-C06, merged in order, each starting on the owner's approval after the previous one is merged and verified. Its prerequisite is met: CS-RG is implemented and macos-qualified for CodeSpace ca306ee (#35, 970acf5). CodeSpace main is 0f585b5, whose code tree equals ca306ee, and it still links this repository at 6e7e065.

Changes

File	Change
milestones.json	P1-RECOVERY is in-progress, qualification not-run, with units (directed and as_of 2026-10-14): P1R-C01 active, P1R-C02 to P1R-C06 not-started
docs/planning/milestones/P1-RECOVERY.md, Korean pair	A dated current-state note, and a "Re-baseline, 2026-10-14" section before the PR sequence. Its table re-bases the entry on CS-RG's qualification, delivery on one pull request per unit, P1R-C01's startup ownership, P1R-C02's store, P1R-C03's one connection with a Claim and epoch fence and its trust boundary, P1R-C04's approval mapping, P1R-C05's Runner-loss accounting through Quiescence, per-unit verification and P1R-C06's scope. The rest of the plan is kept as history
docs/planning/codespace-integration.md, Korean pair	Dated notes in the top suspension notice and in the recovery mode section's notice: that section applies to P1-RECOVERY, the rest of the suspension is unchanged
docs/planning/decisions.md, Korean pair	ADR-001 gains a dated amendment: the independent Runner reads the consumer credential file itself, because no Gateway outlives it to hand it over. The reference date line and the notice list the amendment
AGENTS.md, docs/milestones.md, docs/planning/README.md, Korean README	The dated notes and P1-RECOVERY's row say it has started and P1R-C01 is active

Korean counterparts reviewed; planning-milestones-p1-recovery, planning-codespace-integration, planning-decisions and planning-readme hashes recorded with scripts/check_docs.py record.

What does not change

• P1-RECOVERY is not marked implemented or qualified, and the new mode is not a supported mode until P1R-C06 qualifies it.
• The plan's work definitions, invariants, tests and rollback rules, and the logical groups P1R-P1 to P1R-P3 that scripts/check_docs.py counts, are kept. The suspension of the CSRG-C units, ADR-006 and the rest of the integration specification stays in force.
• No product code, contract, design revision, pin, dependency, release, CI policy or test change. The DG-1 qualified release stays 0.1.0-6e7e065-94d85365.

Verification

At 9b19078, based on main at 970acf5:

• python3 scripts/ci_plan.py --base origin/main: profile affected, stages whitespace, source-contract and documentation, no Rust.
• python3 scripts/validate.py --stages whitespace,source-contract,documentation --diff-base origin/main: passed.
• python3 scripts/check_docs.py: passed, 18 reviewed pairs, 48 work units, 25 logical PR groups.
• python3 -m unittest discover -s scripts -p 'test_ci_*.py': 95 tests passed.

Rollback

Revert the merge (git revert -m 1 <merge commit>). The ledger then reports P1-RECOVERY as not-started again, which would be inaccurate once P1R-C01 is under way.