feat: add governed worktree candidates

[linjiaye929]

Summary

• add host-managed, locked, no-checkout Git Worktree leases for one bounded implementation child
• independently reconcile child mutations into durable content-addressed candidates, then clean up the lease
• add separately governed adoption/discard Tools with clean-base checks, rollback, recovery, and uncertain states
• document the trust boundary, learning path, Java/Flink analogies, resume evidence, and 0.16.0a0 release contract

Why

Giving an implementation child direct access to the parent checkout would combine implementation
and publication authority and could overwrite user work. M6b keeps child completion separate from
candidate readiness and requires a second high-risk WRITE approval before the parent checkout is
modified.

Security Boundary

• the model supplies only task/reason; the host pins repository, state root, Git, paths, Tools, tests, and limits
• materialization reads exact index/object bytes and excludes ignored/untracked content, links, gitlinks, and unsupported modes
• candidate readiness comes from complete-tree/base/ledger reconciliation, not child text or a bounded diff
• adoption revalidates original clean HEAD, paths, and hashes; conflicts write nothing
• partial failures are either proven rolled back or persisted as uncertain
• Worktrees are path separation, not an OS sandbox; multi-file adoption is not power-loss atomic or exactly-once

Verification

• Python 3.12.13: 1184 passed, 13 platform/privilege skips
• Python 3.13.14: 1184 passed, 13 platform/privilege skips
• package branch coverage: 88.49% (85% required)
• Ruff format/check and strict Pyright passed
• Bandit passed; locked runtime dependency audit found no known vulnerabilities
• fixed-epoch builds were byte-identical and archive members passed validation
• wheel and sdist each passed isolated API/CLI plus real delegation/candidate/adoption smoke on Python 3.12 and 3.13