fix(security): pin production dependency versions to lock-file values

[xiaolai]

Automated audit: This PR was generated by NLPM, a natural language programming linter, running via claude-code-action. Please evaluate the diff on its merits.

Bug

Six of eight production dependencies in package.json were specified with ^ caret ranges, allowing automatic minor and patch upgrades on a fresh npm install or bun install (without the lock file):

Package	Before	Pinned to
@ai-sdk/openai	^2.0.80	2.0.100
ai	^5.0.108	5.0.157
dotenv	^17.2.3	17.3.1
gray-matter	^4.0.3	4.0.3
migrate	^2.1.0	2.1.0
pg	^8.20.0	8.20.0
zod	^4.3.6	4.3.6

@tigerdata/mcp-boilerplate was already pinned correctly at 1.3.2.

Fix

Pin each to the exact version already resolved in bun.lock. The installed dependency tree is unchanged — this is a no-op for anyone running from the lock file. The benefit is that CI environments or downstream consumers who install without a lock file (Docker builds, npx, etc.) get a reproducible build rather than a potentially upgraded dependency.

Why it matters

Unpinned ^ ranges can silently pull in a new minor version that introduces a breaking change or a security regression before maintainers have a chance to review it. Pinning to exact versions and using automated tooling (Renovate, Dependabot) for controlled upgrades is a widely recommended practice for published packages and server-side code.

If you prefer to keep caret ranges and rely on the lock file, that's a reasonable policy too — feel free to close this PR. The alternative is to add Dependabot or Renovate config so upgrades are reviewed as explicit PRs.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}