Retire redundant Orchestrator release gating

[edgyarmati]

Summary

This PR retires GedCode's internal Orchestrator release-task and release-approval workflow while
leaving the repository's actual GitHub Actions release pipeline completely unchanged.

After this change, a human can explicitly ask the Orchestrator PM to run an existing GitHub Actions
workflow. That current request is the publishing approval boundary, and the PM uses its ordinary
shell access plus gh for exactly the requested workflow, ref, and inputs. It no longer creates a
second GedCode release task, waits for a separate release gate, or routes the request through a
special dispatch actuator.

State before this PR

• release was a registered Orchestrator task type with its own built-in playbook.
• Release preparation was modeled as a second task derived from exactly one landed feature task.
• The PM exposed releaseSourceTaskId, requestReleaseApproval, and dispatchRelease tools.
• A dedicated server actuator checked the primary worktree, opened a content-hash approval gate,
  and invoked gh workflow run only through that path.
• The PM prompt explicitly prohibited publishing outside the actuator, even when the operator had
  directly requested a workflow run.

This duplicated the repository release workflow, imposed an extra approval abstraction, and blocked
the PM from carrying out a direct operator request.

State after this PR

Active Orchestrator behavior

• Only the feature task type is registered and advertised to PM runtimes.
• The release playbook and dedicated release task provenance path are removed.
• PM/MCP surfaces no longer expose:
  • releaseSourceTaskId
  • requestReleaseApproval
  • dispatchRelease
• Generic approval accepts only the active plan and land gates.
• The release-dispatch service and its GitHub/worktree actuator are removed.
• Historical release-dispatch commands remain decodable but are rejected by the decider with an
  explicit retired-actuator invariant, so an old or stale caller cannot cause an external action.
• The PM prompt now says that an explicit request in the current human conversation authorizes the
  exact requested GitHub Actions dispatch through ordinary shell/gh access. It still prohibits
  unrequested publishing.

Upgrade and historical-data compatibility

This is a compatibility-safe retirement rather than a destructive schema removal:

• Historical release command/event contracts remain present so old logs decode.
• Historical task projection fields and release-dispatch states remain present.
• SQLite migration 053 and release_dispatch_json remain present.
• Existing release status UI remains readable, including historical workflow links.
• Existing project configuration containing task type release is tolerated during upgrade, while
  genuinely unknown task types are still rejected.
• Legacy active release tasks can still be cancelled and subsequently archived/restored/deleted.
• No migration automatically edits, archives, or deletes user tasks.
• Feature-task identity hashing preserves the former null release-source slot, keeping retries that
  straddle the upgrade idempotent.

New release tasks cannot be created, classified, started, gated, or dispatched.

Repository release workflow is intentionally unchanged

There is no diff in any of the following:

• .github/workflows/release.yml
• release.sh
• docs/release.md
• release publication scripts under scripts/

Cross-platform packaging, signing, Sparkle feeds, updater manifests, and GitHub Release publication
continue to use the existing project-owned automation.

Tests and verification

Focused automated coverage passed:

• Server: 9 files, 271 tests
  • active task-type registration and playbook resources
  • PM prompt behavior
  • PM and MCP tool exposure
  • decider rejection of retired task/gate/dispatch operations
  • tolerance of legacy release configuration
  • cancellation of legacy release tasks
  • migration 053 and published database fixtures
  • replay of historical release-dispatch projection state
• Contracts: 1 file, 72 tests
  • includes decode/round-trip coverage for historical release-dispatch events
• Web: 2 files, 87 tests
  • includes historical release status presentation and every published browser persistence fixture

Repository checks:

• bun fmt — passed across 1,477 files
• bun lint — passed with existing warnings and no errors
• bun run typecheck in apps/server — passed
• bun run typecheck in apps/web — passed
• bun run typecheck in packages/contracts — passed
• git diff --check — passed
• explicit zero-diff guard for the repository release workflow and publication files — passed

Risks and operational notes

• A legacy release task that was mid-pipeline cannot resume new worker stages after upgrading. It
  remains visible and cancellable so the operator can settle it without losing historical data.
• Historical release gates and dispatch records remain part of the compatibility model. They are
  intentionally not exposed for new work.
• The direct gh path depends on the PM receiving a current explicit human request, preserving the
  human approval boundary without a redundant application-level gate.

Changelog

CHANGELOG.md documents the Orchestrator retirement under ## Unreleased and explicitly states
that repository release automation remains unchanged.