Do not report a healthy Trino cell as unreachable

[fuziontech]

Fixes the admin console reporting a healthy Trino cell as unreachable:

The Trino coordinator did not answer. Provisioning state below still reflects the config store.
GET /v1/node: trino: query not found

Both halves of that are wrong. The coordinator did answer — with a 404 — and
nothing about a query was involved.

Why /v1/node 404s

Trino binds NodeResource (and therefore /v1/node) in exactly one place:

// NodeManagerModule
case AIRLIFT_DISCOVERY -> install(new AirliftNodeInventoryModule(nodeVersion));  // binds NodeResource
case ANNOUNCE          -> install(new AnnounceNodeInventoryModule());            // does not
case DNS               -> install(new DnsNodeInventoryModule());                 // does not

NodeInventoryConfig defaults discovery.type to ANNOUNCE, and the prod-US
coordinator config sets discovery.uri but never discovery.type, so it takes
that default. The route is not registered and 404 is the correct answer. This
has been true since #1126 shipped; it is not a regression from any Trino image.

What changed

404 and 410 are no longer the same error. They mean different things:
QueryResource throws GoneException — and only GoneException — for a query
that has aged out, so 410 keeps meaning "that query is gone", while 404 now
means "this coordinator does not serve that route".

A missing endpoint no longer marks the cell unavailable. handleStatus let
any node error set available=false. Now an unavailable endpoint leaves
availability alone; every other node error still counts against the cell.

The console can tell the difference. status carries node_stats, so the
UI can say "not reported here" rather than drawing a cell with zero nodes.
/trino/nodes answers 501 rather than 502, because the coordinator answered
and the request was for something this cell cannot provide.

What this does not do

Worker-level visibility is not recoverable for the observer principal as things
stand, and I did not try to force it. The OPA bundle grants
__duckgres_observer query metadata and no catalog at all, deliberately —
that is the stated bargain in policy.rego, and it is why system.runtime.nodes
is denied. Getting the panel back needs either discovery.type=AIRLIFT_DISCOVERY
on the cells or a widened observer grant. Both are real trade-offs and neither
belongs in a bug fix.

Related: the policy comment stating "/v1/node + /v1/resourceGroupState are
MANAGEMENT_READ" is accurate about the annotation, but on these cells that
grant has never had a route to apply to.

Verification

• go vet -tags kubernetes ./controlplane/admin/ clean
• go test -tags kubernetes ./controlplane/admin/ — the 12 failures present are
  identical with and without this change (verified against a stashed baseline);
  all are max_hot_idle_workers schema drift in the local test Postgres,
  unrelated to this code
• go test -tags kubernetes ./controlplane/provisioner/... passes
• UI tsc -b --noEmit clean; vitest run 160/160 across 26 files

New tests cover both halves: a 404 maps to endpoint-unavailable and not to
not-found, a 410 still maps to not-found and not to endpoint-unavailable, and a
cell whose /v1/node is missing still reports available=true with its query
counts intact.

[github-actions]

Test Impact Plan

Deterministic summary of how this PR changes tests, CI runners, and coverage-risk signals.

Summary

Area	Added	Changed	Deleted
Test files	0	2	0
E2E/journey files	0	0	0
Workflow files	0	0	0

Signals

• Test cases: +3 / -0
• Assertions: +14 / -0
• Skips or known failures added: 0
• Workflow continue-on-error added: 0
• Workflow path filters added: 0
• Test commands removed from justfile: 0
• E2E/journey retry lines added: 0

Coverage risk: neutral or increased

No coverage-reduction warnings detected.

[fuziontech]

Self-review before merge found two problems with the first commit; both are fixed in b0ffa7a.

1. Splitting 404 from 410 was too broad, and regressed the query routes.

/v1/query/{id} is always served, so a 404 there is about the id, not the route — JAX-RS answers 404 when it cannot convert a path parameter into a QueryId. Only the aged-out case answers 410.

The first commit sent that 404 to errTrinoEndpointUnavailable, so handleQueryDetail and handleKillQuery lost the clean "query not found" they had before and fell through to 502 "endpoint not served by this coordinator". An operator following a malformed query link would have been told the coordinator does not serve query lookups at all.

Notably the existing comment in handleQueryDetail — "a stale link is an expected 404, not a cell problem" — shows the original author deliberately covered this case, and I narrowed it. The per-query routes now re-read a 404 as a missing query, with a test asserting both directions.

2. The UI change was claimed but not made.

The first commit added node_stats to the type and the API, and the PR text said the console "can say not reported here" — but nothing consumed the field. TrinoCluster would still have drawn "No nodes reported — the coordinator's failure detector has not reported any peers", which reads as an empty fleet rather than as an endpoint the cell was never built with. That page already has status, so it now renders the accurate message.

Verification after the fixes: go vet clean; the full admin suite shows the same 12 pre-existing failures as a stashed baseline and none new (all max_hot_idle_workers schema drift in the local test Postgres); UI tsc -b --noEmit clean; vitest run 160/160 across 26 files.