Describe the bug

For the current main revision, the HTTP static-inventory path handles an
invalid EnabledTools entry differently from the documented startup behavior.

The static builder returns the existing unknown-tool error, but
buildStaticInventory substitutes the full local tool/resource/prompt inventory.
The default HTTP inventory factory then uses that widened static universe.

This is inconsistent with the README and configuration troubleshooting guide,
which say that invalid --tools names cause startup failure.

Affected version

Source-pinned local review at:

a217a7f

This was the repository's main revision during the local preflight. No
deployed server, account, token, or external service was tested.

Steps to reproduce the behavior

The local source-pinned fixture used an HTTP ServerConfig with:

EnabledTools: []string{"get_file_contents", "synthetic_unknown_tool"}

1. Construct the current HTTP handler and default inventory path with
   in-memory request/response objects only.
2. Compare the mixed configuration above with a valid
   get_file_contents-only control.
3. Observe that the valid control omits create_repository, while the mixed
   configuration carries create_repository into the local tools/list response
   through the current default factory path.

The fixture used inert dependencies and did not create a listener, network
connection, external client, account, or tool invocation.

Expected vs actual behavior

Expected: an invalid static EnabledTools entry preserves the typed unknown-tool
error and prevents the HTTP static inventory from being constructed.

Actual: the static helper replaces that error with the full static universe,
which makes the malformed configuration broader than its valid one-tool
control in the local fixture.

Logs

No production logs were collected. The source-bound local evidence and a
focused candidate patch are ready to share in a follow-on pull request if this
behavior is confirmed as unintended.