[bug]: @sf-agentscript/agentforce@2.5.34 (latest) still unusable — dist/ compiled against a newer @sf-agentscript/language than package.json pins (missing export `nullLiteralValidationPass`)

Summary

@sf-agentscript/agentforce@2.5.34 (current latest) cannot be imported after a clean npm install. The package's dist/ is compiled against a newer @sf-agentscript/language than the version its own package.json pins, so the import fails immediately.

This looks like a sibling of #35 (and PR #40): the scope-rewrite part appears fixed in 2.5.34 — dist/index.js now correctly imports from @sf-agentscript/language — but the same publish pipeline still emits dependency pins that don't match what dist/ was built against. Net effect is the same: the published package is broken end-to-end, just with a different error.

Reproduction

mkdir repro && cd repro && npm init -y
npm install @sf-agentscript/agentforce      # resolves 2.5.34
node --input-type=module -e "import { parse } from '@sf-agentscript/agentforce';"

Actual

SyntaxError: The requested module '@sf-agentscript/language' does not provide
an export named 'nullLiteralValidationPass'
    at .../node_modules/@sf-agentscript/agentforce/dist/index.js:354

Expected

The module imports and parse() is callable.

Root cause

@sf-agentscript/agentforce@2.5.34 → dist/index.js:354:

import { symbolTableAnalyzer, undefinedReferencePass, /* ... */,
         nullLiteralValidationPass } from "@sf-agentscript/language";

but its package.json pins the dependency exactly:

"@sf-agentscript/language": "2.5.4"

and that version does not export the symbol:

@sf-agentscript/language	exports nullLiteralValidationPass
2.5.4 (the pinned version)	❌ no
2.18.0	✅ yes

So the compiled output requires a newer language than the manifest allows. Installing @sf-agentscript/language@2.18.0 alongside it makes the import succeed, which confirms the diagnosis.

Suggested fix

1. Have the publish pipeline pin the workspace versions the artifacts were actually built against (the same step that got the scope rewrite wrong in #35 / #40), or simply bump the @sf-agentscript/language pin.
2. Add a post-publish smoke test that installs the packed tarball into a clean directory and does a bare import of every public entry point. Both #35 and this issue would have been caught by that single check, and it would keep the published artifact honest going forward.

Environment

• @sf-agentscript/agentforce@2.5.34 (dist-tag latest)
• resolved @sf-agentscript/language@2.5.4
• Node.js v24.15.0, npm 11.12.1, Windows 11

Notes

Workaround for anyone blocked: @sf-agentscript/parser is unaffected and can be used directly if you only need the AST — that is what I ended up doing. I am building a static authority analyzer that reads .agent authoring bundles and resolves each action's apex:// / flow:// target straight from the file.

Happy to send a PR for the smoke test if that approach is acceptable.

Reproduce the failure with the clean npm install and bare import shown in the issue, then inspect dist/index.js:354 alongside package.json to trace the mismatched language dependency. Read the publish pipeline involved in the scope-rewrite issue and verify how workspace versions become published pins. Done means a clean install can import the package and the packed artifact smoke test covers every public entry point.