build-extension.sh ships a stale backend.assemblyDir when you bump version

[bennett-elder]

manifest.json has two fields that have to agree: version, and backend.assemblyDir, which is <id>/<version>/backend. Nothing keeps them in sync and the build doesn't check.

scripts/build-extension.sh:218 rewrites sdkVersion and passes assemblyDir through as-is:

jq --arg v "$SDK_VER" '.sdkVersion = $v' "$DIR/manifest.json" > "$PKG/manifest.json"

.claude/skills/duplo-extension-dev/reference/02-authoring-guide.md:83 says to bump version on every backend code change. It doesn't say to bump assemblyDir. Follow that literally and you ship a bundle whose assemblyDir points at a directory the bundle doesn't contain.

What breaks depends on the target host:

• Host already has the old version on disk: the install succeeds, the frontend updates, and the old backend DLL keeps running. No error anywhere.
• Host has never seen the old version: the install fails with Extension entry assembly not found: /data/ai-helpdesk/extension-studio/<id>/<old version>/backend/<dll>. The tell is that the version in the path is older than the one being installed.

Repro: take a sample extension from the repo, bump the version, leave the assemblyDir the same, then build and install on a host which has never seen that extension.

The samples are all pinned at 0.1.0, so they're consistent today and nobody hits this until they bump something.

Fix belongs in the build script. assemblyDir is always <id>/<version>/backend, so derive it at bundle time instead of trusting the checked-in value.

Not a loader bug. ExtensionStudioLoader treats assemblyDir as an arbitrary relative path under the studio root, validates it against traversal, and throws when the file is missing. That's correct, and the test fixtures depend on it.

[bennett-elder]

The same drift exists in the other versioned manifest path, skills[].folder — worth fixing in the same pass, since it fails more quietly than assemblyDir.

Four manifests carry it today: samples/helloworld, samples/parent-child (two entries), samples/network-stack, and the duplo-extension-dev scaffold template.

"skills": [
  { "folder": "duplo.examples.helloworld/0.1.0/skills/provision-helloworld", "isBuiltIn": true }
]

The loader resolves it through the same ExtensionPathSafety.ResolveRelativeDirUnderRoot(...) call as assemblyDir (ExtensionStudioLoader.cs:778), but the seeder opens with:

if (!Directory.Exists(folderAbs)) return;

ExtensionStudioLoader.cs:855. The catch above it only fires on a path-safety throw, so a missing folder returns without logging. On a fresh host the extension loads and the skill is never seeded. On a host still holding the old version, the old skill is seeded.

Credit to @jmaggio for spotting that the second path had the same shape.