refactor: shared agent workflows (F01) and one application registry (F02)

Checkpoint for the 2026-09-11 project review remediation. Work by a previous
agent that ran out of context; committed unchanged as a rollback point before
the remaining findings land on top of it.

F01 — the two agent directories had drifted into different processes
- Six shared workflows under `resume_builder/reference/workflows/`; both
  `.agents/skills/` and `.claude/skills/` are now thin entrypoints that route
  to the same file instead of carrying full copies.
- The `.claude` copies were the stale side: fixed bullet line variants and
  character budgets that the newer process had already dropped. Removing them
  is the point of the change, not collateral.
- Parity/link regression test added; corrected the top-level file map, which
  pointed at a directory that does not exist.

F02 — application status was stored in four places and disagreed
- New registry `job_scout/state/applications.json` (26 records) with
  `application_records.py` (schema, validation, transactional write) and
  `application_tracker.py` (add/update, no quota).
- AGENTS.md and CLAUDE.md no longer keep their own status tables; both point
  at `current_applications.md`, generated from the registry.
- Interview-reached is now independent of outcome, so a withdrawal after an
  interview can record both facts. The old tables are preserved verbatim in
  `job_scout/state/history/application_status_before_2026-09-11.json`.

Verification: `python -m unittest discover -s tests -v` — 18/18 pass.
Spot-checked that the detailed SBB and Kdo Cy notes survived the migration
into the registry rather than being flattened.

Known unresolved, deliberately not invented (see FIX_PROGRESS.md):
Aker BP's application date and its Adjacent-despite-79 classification.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM

.agents/skills/setup-build-kb/SKILL.md

@@ -3,80 +3,8 @@ name: setup-build-kb
 description: Build or update the resume knowledge base from structured extractions. Use to normalize employment evidence, maintain the canonical claims registry, add achievements with ownership and metric status, update evidence-tiered skills and role bundles, propagate corrections, and validate the full resume system.
 ---
 
-# Build or Update the Knowledge Base
+# Shared project workflow
 
-## Authority Model
+Read and follow [the setup-build-kb workflow](../../../resume_builder/reference/workflows/setup-build-kb.md) before doing this task. Resolve project paths from the repository root.
 
-The pipeline is:
-
-`source documents -> extractions -> canonical claims -> experience records/bundles -> generated applications`
-
-Generated applications never flow backward into the KB.
-
-Read `resume_builder/canonical/claims.json`, `config.md`, and all relevant extractions before changing normalized sources. Preserve raw source documents. A verified correction must update canonical claims first and then every dependent normalized file.
-
-## Canonical Claim Record
-
-For each employment item or achievement, record:
-
-- stable ID;
-- employer, title, dates and location;
-- factual scope;
-- individual vs shared ownership;
-- allowed verbs;
-- forbidden overstatements;
-- metric/result and verification status;
-- evidence source;
-- last verified date.
-
-When ownership is ambiguous, use contributing/shared scope and ask the user. Do not default to full ownership.
-
-## Experience Files
-
-Experience files explain facts and context. They may contain example phrasings, but those examples cannot override canonical scope and should not be optimized to fixed line counts.
-
-Every achievement section must include canonical ID, source, ownership scope, status, verified result/metric state, relevant skills and role relevance.
-
-## Skills Taxonomy
-
-Use only these evidence levels:
-
-- Production — current.
-- Production — historical.
-- Hands-on — current.
-- Project / proof of concept.
-- Certification / coursework.
-- Unverified / never used.
-
-Do not assign Expert/Proficient/Familiar labels. Add a skill to canonical claims before it can appear in a generated document.
-
-## Role Bundles
-
-Each bundle must contain:
-
-1. Defensible positioning.
-2. Good-fit roles and hard-gate cautions.
-3. Achievement priorities.
-4. Safe reframing rules.
-5. Evidence-backed skills guidance.
-6. Conditional cover-letter guidance.
-
-Bundles may rank evidence; they may not broaden it. Title-defining gaps must be stated explicitly.
-
-## Significance Context
-
-Keep company/industry context separate from candidate impact. Mark external claims for re-verification at application time. Never attach generic scale, economics, customers or market trends to the candidate.
-
-## Correction Propagation
-
-After any correction, search canonical claims, config, extractions, experience files, bundles, support files, templates and active drafts. Historical submitted outputs remain unchanged but update `historical_outputs.json` when they become unsafe for reuse.
-
-## Validation
-
-Run:
-
-```powershell
-python resume_builder/helpers/validate_resume_system.py
-```
-
-Then review the diff for dates, titles, ownership, metrics and skill evidence. Present the changed claim records and affected downstream files to the user for confirmation.
+This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.