chore: refresh SpecGit delivery harness

[LeXwDeX]

Why

specgit issue is blocked on fresh feature worktrees because the checked-in generated harness conflicts with installed specgit 1.10.1. This prevents starting independent deliveries for #433 and #435.

Scope

Refresh only the generated SpecGit harness and preserve the repository-specific acceptance workflow specializations.

Approach

Run specgit init --force, then re-apply the documented specgit-accept.yml deviations: no workflow_dispatch trigger, global npm install -g specgit@^0.5.0, canonical policy check IDs, and retained head-ref checkout behavior.

Acceptance

• specgit issue <existing issue> works on a clean feature branch.
• specgit doctor --json succeeds.
• The acceptance workflow retains repository-specific security and checkout behavior.
• No product code or issue-specific files change.

[LeXwDeX]

Continuation required: after PR #489 merged, clean feature worktrees still reproduce specgit issue existing-issue failing with generated harness assets stale or conflicting. A detached specgit init --force probe at main cd370e8 shows remaining generated differences in specgit-accept.yml, specgit-merge-guard.sh, and removal of obsolete CLAUDE.md. This is the same delivery-blocking WHY; a continuation PR will apply the full generated refresh, restore repository-specific acceptance specializations, and prove specgit issue succeeds.

[LeXwDeX]

Delivery completed and merged via PR #489 (merge commit cd370e8 on main). The Closes #488 reference in the PR body did not fire GitHub's auto-close, so closing manually with evidence: specgit init --force re-run under specgit 1.10.1; all documented specgit-accept.yml specializations restored byte-for-byte (verified by re-init diff + empty git diff HEAD round-trip); specgit doctor --json exit 0. Acceptance item 1 (specgit issue <existing> on a clean feature branch) is being exercised right now by the next delivery, #435.