feat: support version pinning for registry bundles (#1)

[mgoldsborough]

Summary

• The runtime called `mpak.prepareServer({ name })` without a version, so every startup and reconfigure resolved the latest published bundle. That broke reproducibility (redeploy silently picked up new versions) and rollback (a broken release hit every tenant on next restart).
• Added an optional `version` field to the registry-bundle variant of `BundleRef` and wired it through the three `prepareServer` call sites:
  • `src/bundles/startup.ts` — `buildRegistrySource` passes `ref.version`
  • `src/bundles/lifecycle.ts` — `installNamed` accepts a version arg and persists it in the `nimblebrain.json` entry so pins survive restart
  • `src/tools/system-tools.ts` — `manage_app` gains an optional `version` input; workspace install threads it into the `BundleRef` and writes it into `workspace.json`
• Exposed in `src/config/nimblebrain-config.schema.json`, the CLI `Config` type, and the README bundle config table + example.
• The mpak SDK already supports `PrepareServerSpec.version` — no SDK changes.

Out of scope / follow-ups

• The canonical schema at `schemas.nimblebrain.ai` must be updated separately to match the cached copy.
• `configureBundle` (restart after credential change) still resolves via `{ name }` only — restoring the pin on that path requires plumbing `nimblebrain.json` config into the tool handler.
• The Helm chart ConfigMap template (referenced in the issue) lives in a separate deployment repo; that change is tracked outside this PR.

Test plan

• New workspace-store test round-trips a `{ name, version }` bundle entry through disk and verifies unpinned entries remain unpinned
• `bun test test/unit/` — 1726 pass, 0 fail
• `bun run check` / `bun run lint` — clean

Closes #1