refactor: drop dev-cycle-profile.yml for conventions + CLAUDE.md facts

The profile was never parsed — it was prose the skill bodies told the model to read, so most slots were dead, constant across every project, or fiction (the whole pipeline block, including the "tdd is opt-in" claim, was enforced by nothing).

Split it in two: constants become fixed conventions named directly by the skills (new docs/conventions.md), and the few genuinely per-project facts move to each project's CLAUDE.md under '## Skills plugin: project facts'. tdd/fieldtest/docwriter are now always available; the only behavioural toggle left is spec auto-sign.

Delete docs/profile-schema.md and templates/project-profile.yml; add docs/conventions.md and a project-facts section to templates/CLAUDE.md.fragment; rewrite all SKILL/agent prose and the pipeline/design/migration/README/INSTALL docs accordingly.

tdd/agents/tdd-author.md

@@ -45,20 +45,21 @@ You exist to prevent two failure modes specifically:
 
 ## Standing reading list
 
-Read the files configured under `standing_reading.always` plus
-`standing_reading.by_role.tdd-author` in the project profile. The
-defaults include `CLAUDE.md` for role boundaries and the recent
-`git log` for the most recent iter commits — the new behaviour may
-build on what just landed.
+Always read `CLAUDE.md` (for role boundaries) and
+`git log -10 --format=full` — the most recent iter commits, as
+the new behaviour may build on what just landed — plus the
+per-role standing reading the project lists in its CLAUDE.md
+project facts for the tdd-author role.
 
-If the project has a design ledger configured under
-`paths.design_ledger`, walk it for the invariants the new
-behaviour must not cross. A headline test that contradicts a
-ledger invariant is itself a design fork — bounce.
+If the project has a design ledger (its CLAUDE.md project
+facts), walk it for the invariants the new behaviour must not
+cross. A headline test that contradicts a ledger invariant is
+itself a design fork — bounce.
 
 If the `source` is an issue ref, read the issue body in full
-(via the project's tracker, per `commands` in the profile) before
-authoring; the issue body is the description.
+(via the project's issue tracker — its CLAUDE.md project facts;
+always Gitea) before authoring; the issue body is the
+description.
 
 The process below is the single source of truth — the dispatching
 skill file does not duplicate it.
@@ -106,8 +107,8 @@ Each phase completes before the next starts.
    values, not "handles the case correctly".
 3. **Fork check.** Ask: can this one claim be written without
    choosing between two or three plausible behaviours that each
-   have real trade-offs? Walk the design ledger (if configured)
-   for an invariant that would settle the choice. If the choice
+   have real trade-offs? Walk the design ledger (if the project
+   has one) for an invariant that would settle the choice. If the choice
    is genuinely open — the ledger doesn't settle it and the
    description doesn't pin it — this is a design fork. Return
    `BLOCKED` with the fork stated as the design question. Do not
@@ -240,7 +241,8 @@ At most 250 words, structured:
   `brainstorm`).
 - An edit to the headline test's assertion to make it pass — the
   assertion is the contract.
-- Design-ledger edits (the file at `paths.design_ledger`).
+- Design-ledger edits (the project's design ledger, if it has
+  one — its CLAUDE.md project facts).
 - Verdicts like "this whole approach is wrong". Phase 1's fork
   check and decompose mode's two-round limit surface the design
   question; the orchestrator decides the verdict.