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

resume_builder/reference/workflows/make-cl.md

@@ -0,0 +1,42 @@
+<!-- Shared workflow version: 2026-09-11 -->
+
+# Decide and Generate a Cover Letter
+
+## Startup
+
+1. Read `shared_ops.md`, `resume_builder/canonical/claims.json`, `cl_reference.md`, the session, real JD and finished resume.
+2. Run the validator on the resume.
+3. Confirm that the session has a completed resume and a recorded Cover Letter Decision.
+
+## Decision Gate
+
+If the session says NO, explain the recorded reason and stop unless the user explicitly asks to override it. If no decision exists, apply `cl_reference.md` before writing and record YES/NO.
+
+Do not generate a letter merely because an upload field exists or because older workflow expected a three-page package.
+
+## Plan
+
+State in one sentence what the letter adds beyond the resume. Select at most two evidence themes. Verify any named company/product/programme hook from a current primary source and save its URL in the session.
+
+If the only possible content repeats resume bullets or paraphrases company news, change the decision to NO and explain why.
+
+## Generate
+
+- Use the selected audience profile and employer-requested language.
+- International Tech/industry: normally 200--300 words in two or three paragraphs.
+- Swiss/DACH: one A4 page, appropriate formality.
+- Employer-specific: follow the requested format or portal limit.
+- Lead with candidate-role connection.
+- Add motivation, decision context or a genuine connection.
+- Use only claims already present in both the canonical registry and resume.
+- Never introduce a new tool, metric, customer, ownership claim or result.
+
+## Verify
+
+Run:
+
+```powershell
+python resume_builder/helpers/validate_resume_system.py --document <resume.tex> --document <cover_letter.tex>
+```
+
+Compile and inspect the letter. Confirm it is readable, within the employer's limit, and materially different from the resume. Update the session and present the letter for approval. Point to `/critique` next.