ci: add signed-channel publish + gated promote workflow (TR-323)

[jhumel-code]

What

Adds .github/workflows/publish.yml, the producer half of the signed rules distribution. On manual dispatch it:

• builds the engine + rulesctl at the chosen engine_ref,
• assembles a clean export and bundles it into the canonical bundle.tar.gz, printing its digest,
• publishes the immutable, content-addressed bundle-<digest> release,
• signs the channel statement with the production environment secret (RULES_SIGNING_KEY_ED25519); the key id lives in the workflow env,
• self-verifies the candidate statement against the engine's embedded keyring (rulesctl verify) before any promote, and
• re-points channel-<name> in a separate, gated promote job.

Gates and safety

• workflow_dispatch only (never runs on push).
• Promote is gated behind the production GitHub Environment (required reviewer).
• Per-channel concurrency group and tolerant release creates avoid duplicate-run races.
• Self-verify is offline against the embedded trust root, so a statement the fleet would reject can never be promoted (and a first publish does not 404 on a not-yet-existing channel).

Sequencing (do not run until prerequisites land)

• Requires the engine change (embedded signing key in internal/rulesign/keyring.json plus cmd/rulesctl) to exist at engine_ref. Merge the engine branch to main first, or dispatch with engine_ref set to that branch, otherwise the build and self-verify fail closed.
• A workflow_dispatch workflow is only dispatchable once it is on the default branch, so this must merge to main to become usable.
• The signing secret is already set in the production environment.

Refs TR-323.

🤖 Generated with Claude Code