feat: bootstrap @stackbilt/build package

[stackbilt-admin]

Summary

• Ports login, architect, run, scaffold commands from @stackbilt/cli into this dedicated commercial-surface package
• Ports support modules: credentials, http-client, flags, types/scaffold-contract-types
• Removes deprecation-warning shim (its job was to point users here — not needed in the new home)
• Adds release workflow mirroring charter's OIDC trusted-publisher pattern, adapted for a single root package.json (no monorepo loop)

Closes Phase 2 of RFC Stackbilt-dev/charter#112. See Stackbilt-dev/charter#125 for acceptance criteria.

Test plan

• src/__tests__/credentials.test.ts — 9 tests for resolveApiKey env/disk priority; ported verbatim
• src/__tests__/auth-wiring.test.ts — 5 tests verifying architect and run gateway routing; ported verbatim with .js extension imports
• src/__tests__/login.test.ts — 1 test for env-var report path; 3 deprecation-specific tests dropped (code they tested no longer exists)
• npm run build — verify TypeScript compiles cleanly with NodeNext module resolution
• npm test — run all 3 test files via vitest

🤖 Generated with Claude Code

[stackbilt-admin]

Blocking issues found in PR #2:

1. Release workflow uses a pnpm-only flag with npm.

• File: .github/workflows/release.yml line ~116
• Current: npm install --frozen-lockfile
• Problem: --frozen-lockfile is not a valid npm install contract for this workflow; use npm ci (preferred with lockfile) or a valid npm install mode.

2. User-facing command references still point to charter instead of stackbilt.

• src/commands/scaffold.ts lines ~13 and ~20
  • "Run charter architect ..." should reference stackbilt architect ...
• src/commands/run.ts line ~125
  • tip says charter login ... should be stackbilt login ...
• src/http-client.ts line ~126
  • scaffold auth error says charter login ... should be stackbilt login ...

3. No CI checks are currently reported on this branch.

• gh pr checks returns: no checks reported.
• For a package bootstrap PR of this size, we should have at least build/test checks attached before merge.

Please address these blockers, then I can re-review quickly.

[stackbilt-admin]

Follow-up re-review on PR #2 after latest push.

Some blockers were fixed, but there are still blocking issues:

1. CI still fails (build-and-test) because npm ci is used without a lockfile.

• Workflow: .github/workflows/ci.yml line ~17
• Failure is currently:
  • npm ci requires package-lock.json or shrinkwrap
• Fix options:
  • Add and commit package-lock.json, then keep npm ci, or
  • switch CI install step to the same guarded pattern used elsewhere:
    • if [ -f package-lock.json ]; then npm ci; else npm install; fi

2. Remaining stale charter command references (user-facing text) still present.

• src/commands/architect.ts line ~62: Run \charter scaffold`should bestackbilt scaffold`.
• src/commands/login.ts lines ~38-40: guidance still says charter login --key ...; should be stackbilt login --key ....

3. One more command-reference consistency pass is still needed across command help/errors.

• I confirmed the previously flagged run.ts/http-client.ts references are fixed, but the above two locations remain.

Once these are fixed and CI is green, I’ll mark this merge-ready.

[stackbilt-admin]

Re-review update: previous blockers are fixed, but PR #2 is still not merge-ready due to a new CI/typecheck failure.

Current failing check:

• build-and-test (run 26332839893)

Failure details:

• src/cli.ts type errors during npm run build:
  • TS2322: Type 'number' is not assignable to type '0' at lines 14, 15, 16, 17
  • TS2322: Type '1' is not assignable to type '0' at line 18

Interpretation:

• code is inferred too narrowly (likely literal 0) and then reassigned to non-zero values.
• Widen the variable type (e.g. let code: number = EXIT_CODE.SUCCESS) or adjust EXIT_CODE typing usage so assignments are valid.

Once this is fixed and CI is green, I’m ready to sign off.