scan-extension-module: `entry-boundary` check can be bypassed via repo-relative entry paths

[jelloee]

I was reading through the security scanner and noticed the entry-path containment check looks a little off. Here is the relevant block:

// scripts/scan-extension-module.mjs:156-169
const entryRaw = manifest.entry || "";
const allowedRoot = manifestDir;
const manifestRelativeEntryPath = path.resolve(manifestDir, entryRaw);
const repoRelativeEntryPath = path.resolve(repoRoot, entryRaw);
const entryPath = path.isAbsolute(entryRaw)
  ? entryRaw
  : fs.existsSync(manifestRelativeEntryPath)
    ? manifestRelativeEntryPath
    : repoRelativeEntryPath;
if (!entryPath.startsWith(allowedRoot)) {
  pushFinding(securityFindings, { level: "fail", file: manifestPath, rule: "entry-boundary", message: "Entry path escapes repository boundary." });
} else if (!fs.existsSync(entryPath)) {
  ...
}

The intent is "entry must live under the manifest's directory". The bug: allowedRoot is set to manifestDir, but entryPath may be resolved against repoRoot (the repoRelativeEntryPath branch). If manifestRelativeEntryPath does not exist on disk and repoRelativeEntryPath does, the scanner happily uses a path that is outside manifestDir. The subsequent startsWith(allowedRoot) check then fails — but the failure message says "escapes repository boundary", which is the opposite of what the check actually tests (manifestDir, not repoRoot).

So you get one of two surprising outcomes:

• A pack with "entry": "Acode-kit/extensions/registry/EXTENSIONS_INDEX.md" (a file that exists under repoRoot but not under the temp manifestDir) will trip the boundary rule and produce a misleading error.
• For paths that do live inside both, the path used for the existence check is correct, but the variable naming is so misleading that future maintainers will get this wrong.

Two issues, really

1. Wrong error message. It says "repository boundary" but it tests against manifestDir. Either fix the message or fix the check.
2. path.isAbsolute(entryRaw) returns entryRaw unprocessed. An attacker submitting "entry": "/etc/passwd" will be checked against manifestDir and rejected — good — but a tricky case is a UNC / Windows-style absolute path on a non-Windows host. Worth a normalising path.resolve() regardless.

The pattern checks themselves (HARD_FAIL / WARN) look solid; this is just a paper cut in the entry-resolution branch.

Severity: Low/Info. The current check still rejects the bad cases — it's the correctness of the resolved entry path and the clarity of the error that need attention.