fix(coding-agent): emit the Bedrock provider into the CLI bundle

[pmclaugh]

Bedrock provider is missing from the CLI bundle

Summary

The published bin (dist/bundle/cli.js) cannot use any Bedrock model. The first
request fails with:

module.streamSimple is not a function

dist/ built unbundled works fine, and the compiled Bun binary works, so this only
affects npm/node installs -- which is every npm i -g prime-agent user.

Root cause

packages/ai/src/providers/register-builtins.ts loads nine providers lazily. Eight use
a literal specifier that esbuild resolves and emits as a chunk:

import("./anthropic.js")
import("./openai-completions.js")

Bedrock deliberately goes through a variable specifier so browser bundles do not pull
in the AWS SDK:

const importNodeOnlyProvider = (specifier: string): Promise<unknown> => import(specifier);
...
importNodeOnlyProvider("./amazon-bedrock.js")

esbuild cannot resolve a variable specifier, so it emits no chunk and no warning. At
runtime the import still resolves relative to the emitted chunk directory, to a file
that was never written.

Confirmed by building at a18809e0: chunks appear for all eight literal-specifier
providers and dist/bundle/amazon-bedrock.js is absent.

The indirection itself is correct and load-bearing -- removing it (making the specifier
literal) makes npm run check fail, because the AWS SDK then enters the browser smoke
build and @smithy/node-http-handler cannot resolve node:http. So the provider must
stay invisible to static analysis, and the bundler has to be told about it explicitly.

Fix

Declare the provider as a second bundle entry named after the specifier the runtime
uses, so the file lands exactly where the import looks. splitting: true keeps it a
lazily loaded chunk, so the AWS SDK is still only read when a Bedrock model is used.

The entry imports only pi-ai's public ./bedrock-provider export and re-exports the two
names loadBedrockProviderModule() destructures. packages/ai is untouched.

Because esbuild cannot verify this emission, scripts/bundle.mjs now asserts the
artifact exists and fails the build otherwise -- the original failure mode was a silent
omission that only surfaced at runtime for one provider.

Verification

• dist/bundle/amazon-bedrock.js emitted (679 KB) and exports streamBedrock and
  streamSimpleBedrock as functions.
• Still lazy: the AWS SDK appears only in that chunk, which is not in the static import
  closure of cli.js (2 files, 4 KB eager).
• cli.js unchanged in name, size and 0755 mode.
• npm run check passes, including the browser smoke build.
• Removing the entry point reproduces the bug: the build throws
  bundle is missing .../amazon-bedrock.js, and the new test fails.

Tests

packages/coding-agent/test/bundle-bedrock-entry.test.ts asserts the coupling between
the runtime specifier in register-builtins.ts and the entry names in bundle.mjs,
and that the entry bundles to a provider-shaped module. Nothing in the type system
relates those two files, which is why this broke silently.

Note

Emit the Bedrock provider as a separate chunk in the CLI bundle

• Adds bedrock-bundle-entry.js as an explicit entry point that re-exports streamBedrock and streamSimpleBedrock, allowing the bundler to emit an amazon-bedrock.js chunk resolvable by the runtime dynamic import.
• Updates bundle.mjs to declare two named entries (cli and amazon-bedrock) and adds a post-build guard that throws if dist/bundle/amazon-bedrock.js was not emitted.
• Adds tests in bundle-bedrock-entry.test.ts that verify every runtime provider specifier has a matching bundle entry and that the emitted chunk exports the expected symbols.

^{Macroscope summarized 68e1ed1.}

[sethkarten]

Thank you for the report and proposed work. This root cause is now covered by maintainer-owned stacked PR #1158, authored independently from upstream/main.

We did not inspect or reuse this PR's diff, branch, commits, implementation code, or tests; its public description/comments were used only as a bug report. To keep one review surface, this PR is superseded by #1158 and is being closed.

The complete review stack is #1158–#1165. It is being left unmerged for human review after CI and review-bot findings are cleared.