Design: make chain state canonical for live deployment addresses

## Context
During FWSS upgrade checklist review in #508, we clarified that:

- `vX.Y.Z` tags point to frozen deploy commits.
- Mutable rollout facts live in the release issue Run Log, GitHub Release page, and follow-up PRs to `main`.
- `service_contracts/deployments.json` on release branches or tags can become stale after proxy or View switches.

This still leaves a larger design question: should in-tree `deployments.json` remain a canonical source for live addresses, or should chain state become canonical with repo files serving as generated, cached, or compatibility metadata?

## Questions to answer

- What should consumers use to discover live FWSS, PDP, FilecoinPay, StateView, and linked-library addresses?
- Should address getters and proxy implementation slots be the primary source of truth?
- What role should `service_contracts/deployments.json` play on `main`, release branches, tags, Synapse SDK automation, and filecoin-cloud automation?
- How should GitHub Releases record historical rollout state for a specific stack version?
- What validation or tooling is needed to compare `deployments.json` against chain state?

## Expected outcome

Document the intended source-of-truth model and update release automation, release checklists, and downstream integration guidance accordingly.

## References

- https://app.notion.com/p/filecoindev/202606-Retire-in-tree-deployments-json-as-canonical-make-the-chain-the-source-of-truth-for-addresse-38adc41950c1805799fcd0d41ed799d3
- Follow-up from #508 review discussion: https://github.com/FilOzone/filecoin-services/pull/508#discussion_r3471058303
- Related tag semantics discussion: https://github.com/FilOzone/filecoin-services/pull/508#discussion_r3471057306
- Existing checklist update PR: #508

Start by reviewing service_contracts/deployments.json, the questions in this issue, and the linked checklist and tag-semantics discussions. Define the intended source-of-truth model for chain state, repository files, releases, and downstream automation, then update release automation, checklists, and integration guidance accordingly.

Written by the indexing model from the issue text.