fix: require a compiled artifact for entrypoints.jobs

Module discovery gated the compiled-ESM rule on an allowlist,
`["schema", "server", "ui"]`, so `entrypoints.jobs` accepted
`./src/jobs/index.ts`. Every other executable entrypoint required a built
`.js` or `.mjs`; `jobs` did not, purely because it was never added to
that list. It is the second entrypoint to slip through the same way —
`ui` did too, until Phase 6A added it explicitly — which is the argument
against the allowlist rather than against `jobs`.

The rule is now expressed as "every entrypoint except a directory
entrypoint", with `migrations` the only member of that set. A new
manifest entrypoint therefore defaults to the stricter validation instead
of silently escaping it. The same constant replaces the two existing
`=== "migrations"` special cases for the file/directory kind check and
its message, so the one thing that distinguishes `migrations` is stated
once. The directory message is now templated and produces byte-identical
text.

Every other entrypoint guarantee is untouched: package-relative paths,
no traversal, inside-package before and after symlink resolution, the
artifact must exist, and it must be a file.

No runtime was added. `entrypoints.jobs` still has no consumer — it is
declared, validated, and never executed — exactly as it has been since
ADR 0006, and as `ui` was before its host loader existed. The manifest
schema is unchanged and this stays within v4: the field, its type, and
its optionality are all the same, and only discovery's validation of the
declared path tightened.

Compatibility impact is nil in first-party code: no module, template, or
fixture declares a `jobs` entrypoint at all. A third-party module
declaring a source-TypeScript path would now fail discovery, which is the
intended correction.

Tests cover accepted `.js` and `.mjs`, rejected `.ts`/`.tsx`/`.cjs`, a
missing artifact, a directory, a symlink escaping the package, and that
discovery still never evaluates the artifact. The three rejection cases
were confirmed to fail against the previous implementation.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/module-development/README.md

@@ -153,11 +153,11 @@ module's own HTTP routes, and creating relationship-derived grants automatically
 own business logic, are both still later work; this only makes a declared permission *usable*
 through Core's existing, generic surface.
 
-Server and optional schema and UI entrypoints must be compiled ESM `.js` or `.mjs` files. The
-optional migration entrypoint is a directory. All entrypoints begin with `./`, remain inside the
-package, and exist. Production never imports source TypeScript directly. Modules with no tables omit
-`entrypoints.schema`; modules with no migration history omit `entrypoints.migrations`; modules with
-no UI omit `entrypoints.ui`.
+Every entrypoint except `migrations` must be a compiled ESM `.js` or `.mjs` file — `server`,
+`schema`, `jobs`, and `ui` alike. `migrations` is the one directory entrypoint. All entrypoints begin
+with `./`, remain inside the package, and exist. Production never imports source TypeScript directly.
+Modules with no tables omit `entrypoints.schema`; modules with no migration history omit
+`entrypoints.migrations`; modules with no UI omit `entrypoints.ui`.
 
 Unknown manifest properties are still rejected. `ui` is the only entrypoint version 4 adds — a
 `dashboard`, `surface`, `client`, `web`, or `renderers` key fails validation — and the manifest