[P2-E8.8] Fork and upstream collide on 19 Daml package versions

The fork and upstream both claim the same Daml package versions with different content. This is the defect PR canton-network/splice-multi-sync#23 was created to repair at `splice-amulet 0.1.22`, recurring one version up.

A participant that has vetted upstream's build can never accept the fork's package of the same version, and vice versa.

**Verified 2026-09-02** by diffing `daml/dars.lock` on `origin/main` against `upstream/main`. 19 versions collide. The six that are deployed packages, rather than `-test` fixtures:

| package | version | fork | upstream |
|---|---|---|---|
| `splice-amulet` | 0.1.23 | `ed72e57d...` | `8fe7573f...` |
| `splice-amulet-name-service` | 0.1.24 | `ed42a427...` | `cc7d11e7...` |
| `splice-dso-governance` | 0.1.29 | `6e7ba96e...` | `2b680f34...` |
| `splice-wallet` | 0.1.24 | `95bd2424...` | `d4226131...` |
| `splice-wallet-payments` | 0.1.23 | `6757631c...` | `d7297024...` |
| `splitwell` | 0.1.24 | `129863ce...` | `f2ff9522...` |

The other 13 are `-test` packages, which are not vetted on production participants and are lower priority.

**How it happened.** Upstream bumped `splice-wallet` to 0.1.24 on 2026-08-07 (`0a250929e`, "Switch to explicit serializability annotations"). Fork PR #23 then merged on 2026-09-01, minting its own different 0.1.24. Neither side was wrong in isolation; nothing reconciled them.

**Remedy.** `sbt damlBumpPackageVersionsMutate` exists for exactly this (`build.sbt:176`, `:190`) and takes an optional git ref, so `damlBumpPackageVersionsMutate upstream/main` should bump the fork past whatever upstream holds. It needs to run at every upstream sync, before the release-line ref advances.

Neither `release-line-0.7.6` exists on either remote yet, so the deployed packages have not been released with colliding hashes. That is the window to fix it in.

**Acceptance criteria:**
- [ ] No version in `daml/dars.lock` on the fork's `main` shares a version string with a different hash on `upstream/main`, for the six deployed packages at minimum
- [ ] The upstream-sync procedure documents running `damlBumpPackageVersionsMutate` before merging, and where in the sequence
- [ ] A check that would have caught this, or an explicit note on #113 that its gate covers this case

**Related:** #113 [P2-E9.4] predicted this recurrence ("PR #23 fixes it by bumping to 0.1.23, but nothing prevents a recurrence") and is the preventive gate. This issue is the live defect.

**Epic:** ChainSafe/canton-extending-mainnet#71

Start by diffing daml/dars.lock on the fork's main against upstream/main and review damlBumpPackageVersionsMutate in build.sbt at lines 176 and 190. Trace the upstream-sync sequence and the existing gate referenced by #113. Done means the six deployed packages no longer share version strings with different upstream hashes, the procedure documents when to run the command, and coverage of this case is recorded.

Written by the indexing model from the issue text.