chore: unify package manager to bun across repo and CI

[lobinuxsoft]

Problem

The repo currently has three coexisting package-manager sources of truth, which caused a silent drift that only surfaced when local builds started failing:

bun.lock             ← what build.sh (after PR #22) and README target
package-lock.json    ← legacy from npm era
pnpm-lock.yaml       ← what CI workflows actually use

The CI workflows use pnpm:

• .github/workflows/ci.yml → actions/setup-node@v4 + npm install -g pnpm@9 + pnpm install --frozen-lockfile
• .github/workflows/release-please.yml (build-plugin job) → same

Meanwhile build.sh (and the monorepo's build_all.sh) mandate bun.

This is an invisible drift hazard: CI and local can resolve slightly different dependency graphs because they honor different lock files.

Context

The monorepo (capydeploy) standardized on bun — build_all.sh requires it and Hub/Agent frontends are built with it in CI. The submodule lagged behind.

Proposed scope

• Migrate .github/workflows/ci.yml to oven-sh/setup-bun@v2 + bun install --frozen-lockfile + bun run build.
• Migrate .github/workflows/release-please.yml (the build-plugin job) to the same.
• Delete package-lock.json and pnpm-lock.yaml from the repo.
• Update CONTRIBUTING.md / any docs that mention pnpm or npm as the required PM.
• Smoke-test: ensure CI still produces a working plugin ZIP (the inline zip step in build-plugin doesn't depend on the PM, but the frontend bundle it copies does).

Acceptance criteria

• Only bun.lock remains in the repo root.
• CI and local both resolve dependencies from the same lock file.
• release-please.yml still produces CapyDeploy.zip as a release asset on a real release cut.

Why it matters

Mismatched lock files between CI and local mean the released artifact can contain different versions than what a contributor tested. Not critical today (dependencies are thin) but the drift-gap will only grow.