fix(token): vet test-token DARs on every LocalNet participant

.gitignore

@@ -40,3 +40,5 @@ internal/ui/dist/*
 
 # workspace files
 *.code-workspace
+.omo/
+/artifacts/

docs/changes-from-proposal.md

@@ -49,6 +49,7 @@ Every deviation listed here is **intentional**, not an oversight or implementati
   - [Ledger endpoint auto-resolves on every token verb](#ledger-endpoint-auto-resolves-on-every-token-verb)
   - [`--role` defaults to `app-provider`](#--role-defaults-to-app-provider)
   - [`token create` issuer defaults to the acting role's party](#token-create-issuer-defaults-to-the-acting-roles-party)
+  - [`token create` vets the test-token DARs on every participant](#token-create-vets-the-test-token-dars-on-every-participant)
   - [phantom `token settle` reference removed](#phantom-token-settle-reference-removed)
 - [`telemetry` (root-level, new)](#telemetry-root-level-new)
 
@@ -446,6 +447,22 @@ The embedded skill docs are the same artifacts that back the Web UI's Agent Skil
 
 ---
 
+### `token create` vets the test-token DARs on every participant
+
+**Proposal said:** `token create` was described as a creation wizard; how the underlying token packages reach the participants was not specified.
+
+**Shipped:** on the on-ledger path, `token create` uploads and vets the bundled Splice test-token DARs on **all three** LocalNet participants (`sv`, `app-provider`, `app-user`), not only the acting role's participant. Three user-visible consequences:
+
+- On success the command prints `Vetted test-token DARs on sv, app-provider, app-user`.
+- The DARs are cached under `~/.canton-devkit/localnet/.dar-cache/<splice-commit>/`, so repeat runs (and offline runs after the first) do not re-download them.
+- `token create` now fails with an actionable error when any role's participant ledger port is missing from the instance state, instead of silently vetting a subset.
+
+`token mint` and `token transfer --auto-accept` also dial the **receiver's** participant for the accept leg rather than the sender's.
+
+**Why:** Canton only routes a transaction to a participant that has vetted the package. Vetting on the creating participant alone made minting or transferring to a party hosted on another participant fail with an opaque routing error ([#318](https://github.com/bitdynamics-ab/canton-devkit/issues/318)). Cross-participant flows are the normal case on LocalNet, since `app-provider` and `app-user` are separate nodes.
+
+---
+
 ### phantom `token settle` reference removed
 
 **Proposal said:** —