Feature: Release Readiness Dashboard with Artifact, Changelog, and Provenance Gates

## Summary

Add a release readiness workflow that gives maintainers a single CLI and dashboard view of whether Forge is ready to ship, including verification status, changelog coverage, package metadata, Docker image checks, signed artifact provenance, and release-note evidence.

## Problem / Opportunity

Forge already has a serious release posture: npm publishing, multi-arch Docker images, GHCR, signed manifests, provenance, CI gates, release docs, and a `release-check` skill. The current release process is still spread across commands, workflows, docs, and manual judgment. Maintainers need a repeatable way to answer:

- Is the canonical verification chain green locally?
- Is the version bump consistent across package metadata and release artifacts?
- Are changelog and docs updates present for user-facing changes?
- Will Docker and npm release outputs match the expected package contents?
- Are release signatures, checksums, and provenance material ready?
- Which release gate is blocking shipment?

A release readiness dashboard would turn the existing release discipline into an inspectable product workflow.

## Proposed Feature

Build a release readiness workflow available from CLI and dashboard:

- `forge release status` to evaluate local release readiness.
- `forge release plan VERSION` to generate a release checklist from the current repository state.
- Dashboard release view showing verification, changelog, docs, package, Docker, artifact, and provenance gates.
- Gate evidence records that can be exported with release notes.
- Preflight checks for version consistency, package contents, Docker build inputs, signed manifest readiness, and npm/GHCR metadata.
- Optional integration with GitHub Actions status when credentials/network access are available.

## Scope

Expected implementation areas:

- `src/cli/commands/changelog.ts`, `src/cli/commands/update.ts`, and a new or expanded release command surface.
- `src/release/download.ts` and `src/release/verify.ts` as references for artifact verification behavior.
- `src/core/validation.ts` or a release-specific validation module for gate execution.
- `src/ui/server.ts` and `src/ui/public/` for dashboard gate views.
- `.github/workflows/` documentation alignment without requiring live CI in unit tests.
- Docs in `docs/INSTALL.md`, `docs/SETUP.md`, `docs/CLI-REFERENCE.md`, and release guidance.

## Acceptance Criteria

- [ ] Maintainers can run a release readiness command that reports pass/fail/warn gates without publishing anything.
- [ ] Gates include format, lint, build, tests, package metadata, version consistency, changelog presence, docs presence, package file list, Docker inputs, and provenance/signing readiness.
- [ ] Dashboard view groups release gates by category and shows the latest evidence for each gate.
- [ ] Release readiness can export a redacted Markdown or JSON report for release notes or PR review.
- [ ] GitHub Actions status integration is optional and gracefully skipped when unavailable.
- [ ] The workflow never pushes tags, publishes packages, or uploads artifacts unless a separate explicit release command is used.
- [ ] Tests cover gate evaluation, version consistency checks, export formatting, and skipped external integrations with mocks.
- [ ] Documentation explains how readiness gates map to the repository's CI and release workflows.

## Non-Goals

- Automatically publishing npm or Docker releases in the first iteration.
- Replacing GitHub Actions release workflows.
- Requiring network access for local readiness checks.
- Treating warnings as failures without a configurable policy.

## Dependencies / Risks

- Release checks must remain fast enough for maintainers to run locally.
- Package and Docker checks should avoid introducing flaky environment assumptions.
- The dashboard must clearly distinguish local evidence from remote CI evidence.
- Any future publish action must be heavily permission-gated and outside the initial readiness workflow.

## Open Questions

- Should release readiness live under `forge release`, `forge changelog`, or a new command group?
- Should warnings be configurable per project?
- Should the first version support prerelease channels such as beta or nightly?
- Should release evidence be persisted with task/session data or stored as standalone release records?