fix: prepare 0.4.2 release

[whitelonng]

What changed

• allow an owner-only, same-revision/same-aggregate fast-forward code-head rebind for resumable in_progress or blocked git-ref tasks
• remove the consumed adapter-upgrade staging directory after a successful confirmation
• make origin/main the immutable release-check candidate and bump Continuity to 0.4.2
• pin esbuild to the compatible non-vulnerable 0.27.2 release and update release/architecture/workflow documentation

Why

The published 0.4.1 flow could atomically block a task and update the remote fence, then leave tracked .mancode/shared projections. Committing those projections advanced Git HEAD, but a second clone could not resume because the remote code head could not be rebound at the unchanged task revision. Real tarball testing also found that a successful adapter upgrade left .mancode/staging files that made the git-ref clean-worktree gate fail.

Validation

• npm run prepublishOnly: 120 test files, 840 tests passed
• npm audit: 0 vulnerabilities
• real 0.4.2 tarball installed in two independent desktop test clones
• reproduced the 0.4.1 MANCODE_TASK_HEAD_FENCE_MISMATCH, rebound task revision 4 to a fast-forward commit, then pulled and resumed successfully from clone B
• forced a stale Codex adapter, confirmed the upgrade, and verified the operation staging directory was removed

The final origin/main merge commit remains the release candidate and must complete Quality/Windows, release-check, real-host/Beta, npm identity, tag, and GitHub Release gates before publication.