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-extract/SKILL.md

@@ -3,99 +3,8 @@ name: setup-extract
 description: Extract source-grounded career evidence from papers, employment records, project documents, and notes into structured knowledge-base files without promoting inference to fact.
 ---
 
-# Source Evidence Extraction
+# Shared project workflow
 
-Use this skill when adding new evidence to `knowledge_base/extractions/`. Extraction preserves what a source supports; it does not tailor claims to a vacancy.
+Read and follow [the setup-extract workflow](../../../resume_builder/reference/workflows/setup-extract.md) before doing this task. Resolve project paths from the repository root.
 
-## Required inputs
-
-1. Read `config.md` and the anti-fabrication rules in `AGENTS.md`.
-2. Read the complete source material.
-3. Check `resume_builder/canonical/claims.json` for existing facts and identifiers.
-4. Inspect related extraction files so new evidence does not create a duplicate or contradiction.
-
-Generated resumes, cover letters, critiques, and session files under `output/` are never evidence sources.
-
-## Extraction procedure
-
-### 1. Identify the source
-
-Record:
-
-- source filename and type;
-- source date, if known;
-- whether it is primary evidence, user-authored notes, or a secondary description;
-- the person, employer, project, or publication it concerns.
-
-### 2. Separate evidence from inference
-
-For every potentially reusable fact, record:
-
-- the source-supported statement;
-- the exact supporting passage or precise location;
-- any interpretation separately as `Inference`;
-- confidence: `verified`, `user-confirmed`, `needs verification`, or `do not use`.
-
-Never silently convert an inference into a verified claim.
-
-### 3. Capture career facts precisely
-
-When applicable, extract:
-
-- exact employer, formal title, location, and start/end dates;
-- ownership scope and collaborators;
-- work performed, method, technology, and domain;
-- outcome and beneficiary;
-- metrics with units, baseline, period, and attribution;
-- publication status, authorship position, and venue;
-- current versus historical skill use;
-- certification versus practical experience.
-
-For large-company work, describe only the user's component, domain, pipeline, service, or contribution. Do not infer ownership of organization-wide platforms or transformations.
-
-### 4. Record claim controls
-
-For each major claim, include where useful:
-
-- allowed verbs;
-- verbs or framings that would overstate ownership;
-- safe resume wording;
-- known contradictions requiring resolution;
-- whether a metric is verified, qualitative only, or still missing.
-
-### 5. Write the extraction
-
-Create or update a focused Markdown file in `knowledge_base/extractions/`. Use a clear structure such as:
-
-```markdown
-# Subject
-
-## Source
-## Verified facts
-## Ownership and attribution
-## Outcomes and metrics
-## Skills and recency
-## Safe claim seeds
-## Inferences / open questions
-## Conflicts with existing KB
-```
-
-Claim seeds are factual building blocks, not polished resume bullets. Do not add unsupported impact language for relevance.
-
-## Publication rules
-
-- Never infer `published`, `accepted`, or `under review` from a manuscript file.
-- Preserve the user's author position.
-- Institutional funding is not a personal award.
-- Follow `config.md` provenance flags.
-
-## Completion
-
-Report:
-
-- files created or updated;
-- newly verified facts;
-- unresolved contradictions or missing metrics;
-- suggested next command: use `setup-build-kb` to promote reviewed evidence into the canonical registry, experience files, bundles, and support files.
-
-Do not update canonical claims from an unreviewed extraction.
+This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.