Canton 3.5 upgrade + Registry App 0.14 DARs in e2e

## Summary

DA Registry App **v0.14** shipped on 2026-08-21 (Token Standard V2 / CIP-112, and
`ExecutedTransfer` / `ExecutedMint` / `ExecutedBurn` are no longer created). We want e2e
coverage against the new DARs before DA raises the minimum supported version and forces us
onto them.

Testing them requires a Canton upgrade first, so both are scoped here: **Part 1** upgrades
the devstack to Canton 3.5.x, **Part 2** moves the DARs to 0.14 and adds coverage.

## Why the Canton upgrade is required

Every Registry DAR above the 0.12 line is compiled to **Daml-LF 2.3**. Our devstack Canton is
`chainsafe/canton:3.4.8`, which tops out at LF 2.2 and cannot vet them.

```
$ daml damlc inspect utility-registry-holding-v0-0.3.0.dar
damlc: user error (Cannot decode package
ProtobufError "UnsupportedMinorVersion \"3\"")
```

| Release line | registry-app | registry-holding | registry | Daml-LF |
|---|---|---|---|---|
| **0.12 (what we pin)** | 0.7.0 `7a75ef6e` | 0.2.1 `8107899a` | 0.6.0 `a236e8e2` | **2.2** |
| 0.13 | 0.8.2 | 0.2.2 | 0.7.1 | **2.3** |
| 0.14 | 0.9.0 `86fc0823` | 0.3.0 `dd7d2364` | 0.8.0 `f838b87d` | **2.3** |

The three hashes in `deployments/usdcx-dars/manifest.json` are the newest LF-2.2 builds that
exist. **There is no LF-2.2 fallback above 0.12** — even the 0.13 line DA offers as a
stepping stone is LF 2.3. The moment DA raises the floor past 0.12 we are forced into this
upgrade with no intermediate step, so doing it now on our own schedule is the cheaper path.

Worse, the failure is currently silent: `deployments/canton-config/deploy-dars.canton:41-48`
wraps `participant1.dars.upload` in a try/catch that only `println`s. Dropping 0.14 DARs into
`deployments/usdcx-dars/utility/` today produces a half-configured stack plus a warning
buried in container logs, not a failed bootstrap.

---

# Part 1 — Canton 3.4.8 -> 3.5.x

- [ ] **`chainsafe/canton-docker`** — bump the Canton version there and publish the image.
This is the upstream source: `.github/workflows/e2e.yml:47-56` checks the repo out and
runs `./build_contianer.sh`. There is no `chainsafe/canton` on Docker Hub.
- [ ] `docker-compose.yaml:66` — image tag
- [ ] `docker-compose.yaml:90-99` — the healthcheck calls
`com.digitalasset.canton.health.admin.v0.StatusService.Status`. Verify the v0 admin API
still exists in 3.5; if not, move to the current status endpoint. A broken healthcheck
here stalls every dependent service rather than failing clearly.
- [ ] `deployments/canton-config/simple-topology.conf` — validate the config schema against
3.5 (`sequencer.type = BFT`, `storage.type = memory`, `auth-services` wildcard,
`http-ledger-api`). Check whether a protocol-version bump is needed.
- [ ] `proto/daml/com/daml/ledger/api/v2/*.proto` (37 files) — re-vendor and regenerate
`pkg/cantonsdk/lapi/v2` if the Ledger API protos changed in 3.5.
- [ ] Decide on the Daml SDK pin. Our own DARs are LF 2.2 and a 3.5 participant still accepts
them, so `.github/workflows/e2e.yml:63` and the nine
`contracts/canton-erc20/daml/*/daml.yaml` files can stay on 3.4.8 for now. Bump only if
we want to build against 3.5.
- [ ] If we adopt PQS, DA requires **>= 3.5.5** for LF 2.3.

**Gate:** `make test-e2e` green on 3.5.x with the *existing* 0.12 DARs, before touching
anything in Part 2. That isolates Canton-upgrade breakage from DAR-upgrade breakage.

---

# Part 2 — Registry App 0.12 -> 0.14

### 2.1 DAR plumbing — devstack and test only, 9 lines across 4 files

- `scripts/setup/download-usdcx-dars.sh:8` — `UTILITY_BUNDLE_VERSION` `0.12.0` -> `0.14.0`
- `scripts/setup/download-usdcx-dars.sh:47-49` — the three package hashes
- `tests/e2e/devstack/shim/canton.go:28-30` — hardcoded package IDs
- `scripts/setup/usdcx-registry.go:74,76` — flag defaults
- `scripts/setup/bootstrap-usdcx.go:57,58` — flag defaults

New package IDs:

```
utility_registry_app_v0 0.9.0 86fc0823b42911edc70c054466a38e8ad85ab3d90674ef2cba3030485afdfb20
utility_registry_v0 0.8.0 f838b87dbcc296667d72fbb3759435be420eb4a3405a6e4c0a7bd9dfc7eb299c
utility_registry_holding_v0 0.3.0 dd7d236452498ff9a8bb1aa9ae0c4e60a70ac9524bff7cdb1d6935feaa6b7243
```

Production configs use `#package-name` references and need **no** edit — the package names
are unchanged across 0.12 -> 0.14. Note that once we are on 3.5, those `#name` refs resolve
to the highest vetted version, so uploading 0.14 DARs changes what they point at with no
config change. That is intended here, but it is the mechanism to keep in mind.

### 2.2 Make DAR upload failures fatal

`deployments/canton-config/deploy-dars.canton` — rethrow instead of `println`, so a rejected
DAR fails the bootstrap. Without this the whole exercise can appear to pass while USDCx is
quietly unconfigured. Worth doing early — it makes Part 1 debuggable too.

### 2.3 Local registry stub

`scripts/setup/usdcx-registry.go` serves the v1 transfer-instruction paths our SDK calls.
Those are unchanged in 0.14, so the stub only needs new package IDs. It would additionally
need v2 factory endpoints **if** we decide to cover CIP-112 V2 flows in e2e — out of scope
here.

## References

- [Registry App 0.14 release notes](https://docs.digitalasset.com/registry/releases/release-notes/0.14)
- [Registry App 0.13 release notes](https://docs.digitalasset.com/registry/releases/release-notes/0.13) (where LF 2.3 first lands)
- [Transaction History Parsing](https://docs.digitalasset.com/registry/guides/tx-history-parsing)
- [CIP-0112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md)
- [Canton 3.4 -> 3.5 transition](https://forum.canton.network/t/canton-3-4-to-canton-3-5-transition/8777)

Start with .github/workflows/e2e.yml, docker-compose.yaml, and deployments/canton-config/simple-topology.conf to validate the Canton 3.5 upgrade. Run make test-e2e with the existing 0.12 DARs before changing the DAR plumbing, then inspect the listed Go setup files and deploy-dars.canton. Done means the existing tests pass on 3.5.x, updated 0.14 package IDs load successfully, and upload failures stop bootstrap.

Written by the indexing model from the issue text.