fix(reaper): Tier-2 finalization grace + claim-before-act (no dup advance)

Tier-2 reaped a LIVE, still-finalizing monitor: _monitor_agent writes
agent_runs.exit_code FIRST, then does git push / PR / Plane comments before
_finalize_job, and the agent pid is already dead in that window — so the old
"exit_code recorded -> reap now" had no grace and could race a healthy job.
Worse, _reap_known_outcome ran the advance (advance_stage -> enqueue_job)
BEFORE the atomic claim, so a reaper that lost the race had already enqueued
the next stage (dup advance / dup enqueue), violating ADR-001 Р-1.

Fix:
- Tier-2 grace: reap only once agent_runs.exit_code has been recorded for
  >= reaper_finalize_grace_s (new setting, default 300s; > max finalization
  window). A live finalizing monitor is never reaped (FR-1.3/AC-3). New
  finished_age_s column computed in get_running_jobs.
- claim-before-act for exit0: evaluate the canonical QG READ-ONLY (the
  reconciler pattern) to choose the terminal status, then atomically claim
  'done' FIRST; only the claim winner runs the advance. A loser performs no
  side effects -> no dup advance / dup enqueue.

Docs (golden source) updated in the same change: ADR-001, global adr-0011,
README, internals, .env.example, CHANGELOG (also fixes the P3 broken adr-0011
link). New tests cover the grace window, lost-claim no-side-effects, and the
already-advanced idempotent path.

Refs: ORCH-065

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs/architecture/internals.md

@@ -354,13 +354,20 @@ daemon-поток `src/job_reaper.py` (каркас `reconciler`) периоди
 - **Tier-1** — `jobs.pid` мёртв (`os.kill(pid,0)`→`ProcessLookupError`) на
   протяжении `reaper_dead_ticks` подряд тиков (анти-ложноположительность);
 - **Tier-2** — у `agent_runs[run_id]` записан `exit_code`, а `jobs.status` ещё
-  `running` (monitor умер между записью exit_code и `_finalize_job`);
+  `running`. Окно неоднозначно: живой monitor пишет `exit_code` ПЕРВЫМ, затем
+  git push/PR/Plane-комментарии (секунды-десятки секунд) и лишь потом
+  `_finalize_job`; pid агента к этому моменту мёртв в обоих случаях. Поэтому
+  Tier-2 реапит только после finalization-grace `reaper_finalize_grace_s`
+  (`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится;
 - **Tier-3** — backstop: job висит `running` дольше `reaper_max_running_s`.
 
 Реап атомарен (`UPDATE jobs SET ... WHERE id=? AND status='running'` + `rowcount`,
 как `claim_next_job`) → совместим со стартовым `requeue_running_jobs` без двойной
-обработки. Действие переиспользует контракты: exit0 → gate-driven
-`_try_advance_stage`+`_finalize_job` (источник истины — QG); exit≠0/неизвестно →
+обработки. Действие — **claim-before-act**: для exit0 канонический QG оценивается
+read-only ПЕРЕД атомарным claim, затем claim `done` ПЕРВЫМ и только победитель
+claim делает `_try_advance_stage` (advance+enqueue) — проигравший (поздний monitor
+/ стартовый requeue) не выполняет побочных эффектов (нет дубль-advance/-enqueue);
+источник истины — QG, не «exit0»; гейт красный или exit≠0/неизвестно →
 `attempts<max`→`queued`, иначе `failed`+Telegram. Тот же поток на старте и
 периодически делает проактивный реклейм stale/dead merge-lease (`merge_gate.py`:
 `pid_alive`/`reclaim_stale_lease`). never-raise; kill-switch `ORCH_REAPER_ENABLED`