Schedule daily OpenTimestamps anchoring of the witnessed journal

[MaxGhenis]

What

A daily GitHub Actions cron (plus workflow_dispatch) that anchors the witnessed observation journal in Bitcoin via OpenTimestamps. Companion to #182, which adds the tool, the proofs for releases 0000–0014, and the docs on codex/thesis-ledger-facts.

Scheduled workflows only run from the default branch, so this definition lives on main and operates on a checkout of the journal branch:

1. python3 scripts/ots_anchor.py run — stamp any release manifest lacking a proof, upgrade pending proofs whose calendar attestations have confirmed into Bitcoin. Idempotent; the tool is stdlib-only and the ots client is pinned (opentimestamps-client==0.7.2).
2. Commit changed proofs under ots/ back to the journal branch as github-actions[bot], with a rebase-and-retry push loop (proof commits touch neither the data surface nor the gate surface, so they cannot collide with resolver append PRs).
3. python3 scripts/ots_anchor.py verify — fail the run if any proof stops binding to its manifest's exact bytes.

Merge order

Safe to merge before or after #182: the job exits cleanly with a notice while scripts/ots_anchor.py is not yet on the journal branch. The first effective run needs #182 merged; workflow_dispatch can trigger it immediately after.

🤖 Generated with Claude Code

[MaxGhenis]

Fable+Sol gate result: changes requested, and I agree with the peer on all four points, so this PR does not merge as written.

1. The publication path cannot land. The journal branch requires Append gate, Arch checks, and Trusted base append gate (strict), and a ruleset requires the append-gate workflow by path and ref. A fresh commit direct-pushed by GITHUB_TOKEN carries no check results and token pushes do not trigger workflows, so the rebase-and-retry loop can never succeed. The "auto-PR fallback" in the body has the same problem: PRs opened with GITHUB_TOKEN do not trigger pull_request workflows either.
2. Privilege boundary. The job persists a contents: write credential into a checkout of the mutable journal branch and then executes scripts/ots_anchor.py from that branch. That script is not in the append gate's GATE_SURFACE, so a data proposal that passes the gate could change privileged code that later runs with a write credential.
3. Verify before push, not after. A proof that fails to bind would reach the remote before the job fails, and run skips Bitcoin-complete proofs without rechecking their binding, so it would not self-heal.
4. Rebase retry can publish a stale tree. A manifest appended to the tip between attempts would go out without its proof.

Rework (in progress, new PR against main): the tool, tests, workflow, and the ots/ proofs all live on main, the trusted branch the workflow already runs from. The job checks out the journal branch credential-free into a separate path purely as manifest input, runs main's pinned script, verifies the whole tree, and commits proof changes to main only (never to the journal branch), re-running stamp + verify after any rebase. #182 and this PR will be superseded by that PR; the 15 already-attested proofs (Bitcoin blocks 963253 / 963257) carry over byte-for-byte, since a proof binds to manifest bytes, not to where it is stored.

[MaxGhenis]

Superseded by #229 (anchoring from main: tool, tests, workflow, and proofs on the trusted branch; the journal branch read credential-free as input only). The fifteen proofs from this PR carry over there upgraded in place, now with Bitcoin attestations on disk, plus proofs for manifests 0015–0019. This PR stays open until #229 merges, then closes.