fix(baton): inherit task declarations from explicit Charter origins (#427)

[montfort]

Closes #427. Estoa's adoption report reproduced a task under a declared implement/new Charter remaining undeclared/frontier on Baton 0.2.1. It now inherits the declaration when the explicit originating_spec Charters resolving to its sibling spec all declare the same thing, producing implementer/economic under the unchanged default policy.

Parents must resolve inside the project and agree on work_verb/design_provenance. Missing or disagreeing parents, and unreadable Charter frontmatter, remain conservative (the latter is now named on stderr). Tasks gain no declaration slot and do not inherit the whole Charter's effort estimate. This avoids guessing from titles or picking the first/newest Charter. The decision is recorded in .straymark/07-ai-audit/decisions/AIDEC-2026-09-13-001-baton-task-parent.md.

Validation

• Before the fix: new synthetic regression suite 3 failed / 5 passed.
• Final cargo test -p straymark-baton --locked --offline: 93 passed, no failures or ignored tests (84 existing + 9 new). Binary/doc zero-test harnesses are excluded from this count.
• The new cases cover all verbs, provenance, filtered inventory, multiple/missing parents, invalid declarations, external symlinks, CLI read-only behavior and mandatory --dry-run.
• cargo clippy -p straymark-baton --all-targets --locked --offline -- -D warnings passes; rustfmt check on the new test file and git diff --check pass.
• straymark validate passes with existing warnings. Full Charter schema validation is not claimed for this clean checkout: its ignored, generated framework tree is absent. No additional framework copy was installed.

Scope and bookkeeping

The ratification's prototype-status note documents partial task inheritance. The Track C kit now points batches to the ratified ledger slot, while explicitly retaining batch harvesting as pending (#428). Multi-Charter task ownership, direct spec declarations and follow-up/batch inheritance need separate work. Risk escalation and model execution are unchanged; no calibration, real cost savings or human documentary acceptance is claimed.

No version bump or release. Governed record: .straymark/07-ai-audit/agent-logs/AILOG-2026-09-13-001-baton-task-inheritance.md (review pending). The new integration tests and this PR contain only synthetic examples; no private Estoa source or unit titles are published.

Maintainer review amendments (857ffc5)

• Agreeing parents inherit (was: exactly one parent). Under the charter-chain pattern a spec gaining an agreeing Charter no longer unclassifies its tasks retroactively; any disagreement, or a parent that declares nothing, keeps them undeclared.
• Parents read from raw frontmatter: a Charter the typed parser rejects still counts as a parent; only unreadable frontmatter disables inheritance, and classify/route say which Charter did.
• AIDEC-2026-09-13-001 amended and accepted; new AILOG-2026-09-17-001. cargo test -p straymark-baton --locked: 97 passed (13 in task_inheritance.rs); clippy -D warnings clean.

[montfort]

Maintainer review

The fix is correct: canonical resolution, the out-of-project symlink guard, no effort inheritance, context_spec not treated as a parent, read-only. Measured read-only against three corpora (git status unchanged): Sentinel 0 → 86 tasks classified (007-usageguard), Estoa 0 → 39, LNXDrive unchanged.

Two changes pushed in 857ffc5 on top of the original commit:

1. Agreeing parents inherit instead of requiring a unique parent. Sentinel's specs 002–005 carry 2–8 Charters each. Under "exactly one parent", a spec loses its task classification as soon as it gains a second Charter, even one that declares the same thing, and that change applies retroactively to tasks already done. Uniqueness never established which tasks a Charter owns either. Agreement is compared on the declaration, not on the derived class; a parent that declares nothing counts as disagreement.
2. No silent project-wide disable. Parents are now read from raw frontmatter, so a Charter the typed parser rejects still takes part in the check. Only unreadable frontmatter disables inheritance, and classify/route name that Charter on stderr instead of only suggesting to declare a verb.

This needs a separate fix: Baton's inventory walks nested git worktrees (.worktrees/), which inflates Estoa's local task count. It is not caused by this PR and will be handled in its own PR.