[Feat]: A live deployment should record its addresses in this repository automatically

[re-gius]

Component

Other

Priority

P1

Summary

No live deployment updates deployments/<network>/<chain-id>.json. dotns-releases runs the pipeline against a checkout of this repository, but commits only its markdown report; the manifest the pipeline writes is discarded with the runner's checkout. So after every deployment someone copies addresses out of a report table by hand.

That was a documentation problem before #118. Now that a release publishes those addresses, a manifest that lags a deployment ships wrong data to consumers instead of merely reading wrong in a doc.

The implementation lives in dotns-releases, but the issue belongs here: the manifest and the published artifact are in this repository.

Proposal

After a successful live deploy, dotns-releases opens a pull request here with the manifest it produced.

• Live only. Rehearsals deploy against an ephemeral network, so their addresses are not a fact about any lasting chain.
• Every live deploy, not only when something moved. Otherwise "the manifest reflects the last deployment" is only true of deployments that happened to move an address. If the file is unchanged, skip the PR and say so in the run summary.
• Record the deployed commit as _deployedFrom in the manifest. The _ prefix means the release generator already drops it, so it stays out of the published artifact: it is provenance, not an address. Today the report records a ref such as master, which identifies nothing.
• Restrict live deploys to tags. The release flow in RELEASE_ARTIFACTS.md already asks for one, and a tag makes _deployedFrom reproducible where a branch does not.
• Never auto-merge, and fail soft: if the write-back cannot run, comment on the triggering issue and leave the deploy green. The deploy succeeded; bookkeeping failing afterwards must not report it as broken.

Acceptance criteria

• A live deploy opens a PR here with the manifest it produced, carrying the expected-versus-actual table, the network, the chain id, the deployed commit, and links to the triggering issue and run.
• A live deploy that changes nothing opens no PR and says so in the run summary.
• A rehearsal opens no PR and pushes nothing.
• _deployedFrom is recorded, and absent from the published deployments.json.
• The live deploy template accepts only a tag; rehearsals still accept any ref.
• A write-back failure leaves the deploy reported as successful and comments on the issue.
• Exercised end to end on a testnet before the first mainnet deployment.