docs: add v0.8.59 triage runbook and scratch-branch integration guidance

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

CLAUDE.md

@@ -0,0 +1,51 @@
+# Claude Repository Guidance
+
+Read `AGENTS.md` first. This file exists as a compatibility instruction source
+for Claude-based agents working in this repository.
+
+## Stewardship Defaults
+
+- Treat community PRs and issues as maintainer evidence. Inspect code, tests,
+  linked issues, comments, and CI before merging, harvesting, closing, or
+  deferring work.
+- Do not tag, publish, create a GitHub Release, or push release artifacts
+  without Hunter's explicit approval.
+- Keep CodeWhale branding while preserving first-class DeepSeek model/provider
+  support and legacy migration care.
+- Preserve contributor credit for harvested work with authorship,
+  `Co-authored-by`, `Harvested from PR #N by @handle`, and changelog/release
+  notes where applicable.
+
+## Scratch Integration Branches
+
+- For release queues, create disposable local branches from the real landing
+  branch, for example `scratch/v0.8.59-pr-train-YYYYMMDD`.
+- Use the scratch branch to merge or cherry-pick candidate PR heads in batches
+  and learn which conflicts, tests, and overlaps are real.
+- Do not ship the scratch branch itself. It may contain noisy merge commits,
+  partial conflict resolutions, and unrelated PR interactions.
+- After the scratch experiment, move only the safe result back to the release
+  branch as narrow commits or direct merges. Keep each final commit explainable
+  and testable.
+- A PR that is clean against `main` is not necessarily clean against a release
+  branch. Test mergeability against the branch that will actually receive the
+  work.
+- For already approved PRs, treat approval as a strong priority signal. Still
+  inspect diffs, comments, check results, and release-branch conflicts before
+  landing.
+
+## v0.8.59 Release Work
+
+- Base release triage on `codex/v0.8.59-release-ready` unless Hunter gives a
+  newer branch.
+- Work the queue in this order: release blockers, recently approved PRs, clean
+  PRs with small scope, blocked PRs with obvious fixes, dirty PRs that can be
+  harvested safely, then larger architecture issues.
+- Prefer batching PR conflict discovery on scratch branches, then harvesting
+  reviewed, credited, tested slices back into the release branch.
+- Before claiming an issue is done, verify whether the release branch already
+  contains equivalent work. If it does, prepare the GitHub note/closure path
+  instead of reimplementing it.
+- For the current v0.8.59 queue, start with
+  `docs/V0_8_59_RELEASE_TRIAGE.md`, then refresh live GitHub state before
+  taking action.