fix(server): a bad publisher.json answers 424, and a hidden source says why it was refused

[jswir]

Two bug fixes, one commit each. Both came out of testing the modeling workflow against a local Publisher after #1206, and a service-side session hit both independently.

1. A bad publisher.json answered 503

A malformed explores, an unknown scope, or two scope values that disagree answered 503 "Package-load worker pool unavailable". That's the author's mistake, but callers logged it as a server outage.

• Cause: the manifest is read inside the package-load worker. The three throws were plain Errors. On the way back, the pool rewrapped everything except compile errors as a worker outage.
• Fix: they now throw PackageManifestError. It sets name, which the pool already sends across, so the class survives and Package lets it through at both worker call sites.
• Status: 424, the same status a package that fails to compile already gets on reload. The request was fine; the package it depends on is not.

2. A hidden source's 404 read like a typo

In a package curated by index.malloy, a modeler who saves users.malloy and queries it gets No queryable model "users.malloy". Over MCP that became Resource not found ... verify the identifier is spelled correctly. The name is real.

The 404 was worded like a missing name so that a hidden gated source can't be told from one that doesn't exist. An ungated hidden source has nothing to protect that way. Curation isn't access control, and /compile (exempt from the boundary) already answers a hidden file differently from a missing one.

Now, when the target is real and the refusing model has no #(authorize) anywhere, the 404 says why:

No queryable model "users.malloy". It is not on this package's published surface,
"index.malloy": only what that file exports is queryable, and only through it.
Fix: import it in "index.malloy", add it to that file's export { ... }, and address
the query to "index.malloy".

• Still a 404: this is OffSurfaceError, a subclass of NotQueryableError.
• Unchanged: a name that doesn't exist, and every refusal in a model with any gate, keep the plain message. The gate check uses hasAnyAuthorizeNote(), which answers true for unreadable IR, so any doubt gets the plain message.
• Source and view both named: the refusal now names the source, since that's what is off the surface.
• MCP: execute_query passes the message through with "this is curation, not a typo", instead of the spelling advice.
• Docs and skills: docs/discovery-and-access.md, malloy-publish and malloy-source-unreachable are updated. The MCP skills bundle is regenerated.

Behaviour change: two tests pinned the identical 404 for packages with no gates (query_boundary.spec.ts, surface_widening.integration.spec.ts). They now pin the new contract. A new test pins that a gated model still refuses a hidden name and a missing one with identical text.

How this was checked

• Bug 1: a new test loads all three manifest errors through the real worker pool and asserts 424 with the author's message. With the pool change reverted, it fails with the exact 503 text.
• Live server: a local build served a scaffolded package built from the malloy-samples ecommerce data. The hidden file's 404 explained itself over REST and MCP. A missing file stayed plain. A malformed explores answered 424 on reload.
• Unit suite: 4190 pass. 35 config.spec failures are the known local bun 1.4 issue and also fail on main.
• Integration: 347 pass, run with MCP_PORT=4044 because 4040 was taken locally. compile_authorize_http (3) and concurrent_package (1) fail the same way on unmodified main. One MCP semantic spec couldn't bind port 4050, which another local process held.

Not in this PR

• Bug 1's own message still suggests "explores": ["index.malloy"], a deprecated key. Worth rewording separately.
• Modelers still can't query a new file without editing index.malloy. The fix for that, a server-level draft mode, is a separate design.

🤖 Generated with Claude Code

[Sha-Bang]

3 should-fix, 1 nit.

• packages/server/src/service/environment.ts:839: compile_model at scope: "package" still turns a bad publisher.json into a 503.
• packages/server/src/mcp/handler_utils.ts:67: PackageManifestError has no MCP branch, so reload_package calls it an unexpected internal error and says to retry.
• packages/server/src/service/query_boundary.spec.ts:1030: the gated-model test only pins the ad-hoc refusal. The named-source and hidden-file refusals in a gated model are not pinned.
• packages/server/src/service/package_worker_path.spec.ts:694: the new it.each separated the "kept last" note from the test it describes.

environment.ts:839 (outside this diff, so not inline): this is a third worker call site. The package-scope compile calls getPackageLoadPool().loadPackage directly, and this catch rewraps every rejection as ServiceUnavailableError. Edit publisher.json to a bad explores and run compile_model with scope: "package", and you still get 503 "Package compile worker unavailable: Invalid "explores" ...", the outage-shaped answer this PR removes elsewhere. The new comment at errors.ts:20-22 says a bad manifest no longer lands in that branch, and on this path it still does. Could this catch let PackageManifestError through (and probably ModelCompilationError/MalloyError too), the way Package.loadViaWorker now does?

[jswir]

On environment.ts:839: eb35be9 lets PackageManifestError through the package-scope compile catch, pinned in compile_scopes.spec.ts. 8cbd5ec also lets MalloyError and ModelCompilationError through, so all three worker call sites now split errors the same way.