sign-artifacts can't auto-commit new signatures to main (needs bot push access or a PAT)

## Context

registry#334 built the Ed25519 `sign-artifacts` CI job and registry#335 backfilled all 83 published capabilities. Signing itself works end to end (verified: `docs/decision-log.md` entry 77).

The one remaining gap: on a **future** merge to `main` that publishes a *new* capability, the `sign-artifacts` job signs the artifact but **cannot commit the `signature.json` back to `main` on its own**. `traverse-framework/registry`'s `main` is protected by the org `traverse-governance-*` rulesets, and `github-actions[bot]` is not on their bypass list. The `GITHUB_TOKEN` also can't open a PR that runs CI (GitHub blocks `GITHUB_TOKEN`-triggered workflow runs), so an auto-opened PR can't satisfy required checks either.

## Current behaviour (registry#339)

The job always uploads `capabilities/**/signature.json` + `catalog/signing-key.pub` as the `artifact-signatures` workflow artifact, and on `push` events attempts the direct commit, degrading to a `::warning::` (run still succeeds) when the push is refused. So new publishes are *recoverable* — a maintainer downloads the artifact and opens a normal PR — but not automatic. Runbook: `docs/artifact-signing.md` step 3.

## Options

1. **Dedicated bot PAT / GitHub App token** as a repo secret, used by the job to push directly (or to open a PR that *does* trigger CI). Keeps `main` protection intact; adds one secret to rotate.
2. **Add `github-actions[bot]` to the `traverse-governance-*` ruleset bypass list** for `main`. Simplest mechanically, but weakens a governance ruleset — a deliberate governance decision, not a routine toggle.
3. **Leave as-is** — maintainer PRs the signature after each new-capability publish using the uploaded artifact. Fine while publish volume is low.

## Recommendation

Option 1 if/when publish cadence makes the manual step annoying; Option 3 until then. Needs an owner decision — not something to pick unilaterally.

## DoD

- [ ] Decision recorded (here or `docs/decision-log.md`).
- [ ] If option 1: PAT/App token provisioned, `sign-artifacts` job updated to use it, verified on a real new-capability publish.
- [ ] `docs/artifact-signing.md` step 3 updated to match the decision.

Start with the sign-artifacts CI job and docs/artifact-signing.md step 3, then review the governance constraints and the three options in this issue. Record the owner decision here or in docs/decision-log.md; if automation is chosen, provision the token, update the job, verify a real new-capability publish, and align the runbook.

Written by the indexing model from the issue text.