feat: distribute the CLI as a dpm component

[nicosampler]

Summary

Closes #32

Ships canton-barebones through a second distribution channel: a dpm component with self-contained per-platform binaries, published to ghcr.io/bootnodedev/canton-barebones on every release. Canton developers can install it with dpm and run dpm canton-barebones <cmd> (alias dpm cbn) without Node on the host. The npm channel is unchanged and both channels ship the same source and version.

Changes

• Compile the CLI to a standalone binary with Bun; the bundled templates/ are embedded at compile time and materialized into the project's .generated/ at runtime (docker compose needs a real file path). The Node/npm code path is untouched — no runtime branching, the entry point decides.
• Unit tests for the embedded-template materialization, plus a fail-loud error when the binary requests a template that was never embedded.
• Apache-2.0 LICENSE at the repo root (required by dpm publish component) and license field in package.json.
• scripts/build-component.js + dpm-component/component.yaml: cross-compiles the five platforms and assembles the per-platform component layout (binary + manifest + LICENSE; windows variant points at the .exe).
• CI workflow for PRs: unit tests, full component build, dpm publish component --dry-run validation, and a smoke test of the linux binary. dpm is pinned by version + sha256 via a shared composite action (.github/actions/setup-dpm).
• Release workflow publishes the component to ghcr (semver + latest tags) right after a successful npm publish, using the workflow's GITHUB_TOKEN — no new secrets.
• README documents both dpm installation flows (and drops the stale "package name TBD" note); docs/dpm-local-testing.md captures the local end-to-end test against an ephemeral registry, including dpm quirks.

Acceptance criteria

• The CLI compiles to a self-contained binary (no Node on the host) for linux/amd64, linux/arm64, darwin/amd64, darwin/arm64 and windows/amd64
• Each release publishes the component to ghcr.io/bootnodedev/canton-barebones with a strict-semver tag plus latest
• Pull requests validate the component layout and manifest (dpm publish component --dry-run) and smoke-test a compiled binary
• The npm channel is unchanged (same code path, tests green)
• README documents both dpm installation flows; a local end-to-end testing guide exists

Note: the ghcr publish path runs for the first time on the next release; making the package public in the org settings after that first publish is a one-time manual step (documented in the workflow comments).

Test plan

Automated tests

• scripts/embedded-templates.test.js (new): materialization to .generated/, npm-channel passthrough, stale-copy rewrite, fail-loud on non-embedded files. Run with npm test (34 tests).
• CI component job: builds all five platforms, validates with dpm publish component --dry-run, smoke-tests the linux binary (init from embedded templates).

Manual verification

Full end-to-end against a local OCI registry (now documented in docs/dpm-local-testing.md): published the component to an ephemeral registry:2, installed it with dpm add component in a clean project, and ran init, validate, start (full Canton stack up and healthy), status --json, and reset through dpm canton-barebones / dpm cbn on darwin/arm64.

Breaking changes

None.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.