fix(widget): hardcode @deepgram/agents range, drop publish-time pin step

[lukeocodes]

Summary

@deepgram/agents-widget@0.1.2 was tagged after #40 + #41 merged, then publish-widget failed again at the Pin step:

ReferenceError: SDK_VERSION is not defined
    at [eval]:4:42

Root cause

the Pin step had a latent bash-to-JS interpolation bug:

SDK_VERSION=$(node -e "...") # bash var
node -e "
  pkg.dependencies['@deepgram/agents'] = SDK_VERSION;  # treated as JS identifier, not interpolated
"

SDK_VERSION inside node -e "..." is a JS identifier, not a bash variable. it should have been '$SDK_VERSION' or process.env.SDK_VERSION. the bug pre-existed in the workflow before today's launch, but never executed: the original publish-widget always failed earlier on the broken sibling-checkout. now that the rest of the job works, this bites.

The right fix isn't to repair the Pin step

widget releases are independent of SDK releases. widget should declare a real semver range on @deepgram/agents the same way @deepgram/react and @deepgram/ui do for their cross-package deps. bun resolves widget's @deepgram/agents to the workspace SDK locally because workspace SDK 0.1.x satisfies ^0.1.1, so dev workflow is unchanged. at publish time the range publishes as-is.

Changes

• packages/widget/package.json: @deepgram/agents goes from workspace:* to ^0.1.1. matches the pattern @deepgram/react and @deepgram/ui use for their cross-package deps.
• .github/workflows/npm-publish.yml: drop the Pin step entirely. replaced with a defensive guard that fails publish if any workspace: string is still present in widget dependencies, so npm doesn't accidentally publish a tarball with workspace-protocol strings.

Local verification (fully clean checkout)

$ rm -rf node_modules packages/*/node_modules examples/node_modules bun.lock
$ bun install
522 packages installed
$ ls -la packages/widget/node_modules/@deepgram/agents
lrwxr-xr-x  ... agents -> ../../../sdk
$ bun run build
✓ widget.umd.js  384.30 kB │ gzip: 90.06 kB
$ bun run test
107 pass / 0 fail (78 SDK + 29 widget)

bun symlinks widget's @deepgram/agents to the workspace SDK because the workspace SDK version (0.1.1) satisfies ^0.1.1. dev workflow unchanged.

State on main

• agents-widget-v0.1.2 GitHub release exists ✅
• @deepgram/agents-widget@0.1.2 is not on npm ❌
• after this PR merges, release-please opens release agents-widget 0.1.3. merging that runs the (now actually fixed) publish-widget and @deepgram/agents-widget@0.1.3 lands on npm with provenance.

Why we don't keep republishing the failed tag

each release-please flow attaches a GitHub release to the merged commit. the publish failure is local to that workflow run; the release tag and version remain. simplest forward path is to let release-please cut a fresh patch each time. once the pipeline is actually green end-to-end, this stops happening.

Defensive guard explained

the new guard is intentionally pessimistic. if anything regresses widget's deps to workspace: syntax (a refactor, a copy-paste, etc.), the publish job hard-fails before npm publish instead of pushing a broken tarball. there is no scenario where we want to publish a package containing workspace: strings.

Test plan

• clean repo + clean install + clean build + tests
• bun resolves widget's @deepgram/agents to the workspace SDK
• CI green on this PR
• release-please opens release agents-widget 0.1.3
• merge that PR -> @deepgram/agents-widget@0.1.3 on npm with provenance