feat(security): filter aggregate reads by host scope (phase 3)

[malickyeu]

Summary

Yes, the leaks were fixable. Phase 2 stopped a scoped user acting on another
host; it didn't stop them reading about it. This closes that — invariant 4 of
the design note, the one phase 2 left open.

Type of change

• Bug fix
• New feature
• Docs only
• Refactor / chore

Checklist

• go test -short ./... and go vet ./... pass
• gofmt gate is clean (gofmt -l $(git ls-files '*.go') after staging)
• Frontend type-checks (cd web && npx tsc --noEmit)
• Rebuilt and committed web/dist
• Added/updated tests for the change
• Updated docs/ and added a CHANGELOG.md entry for user-facing changes

Notes for reviewers

It was smaller than the design note feared, for an instructive reason: most of
the "aggregates" aren't aggregates. Topology, the events feed, disk usage, stats
overview and published ports are each per-host reads taking ?host= — so phase
2's middleware check already covered the ones that map to a section. What actually
leaked was narrower and sharper:

1. Three dashboard routes map to no section — /api/stats/overview,
   /api/system/df, /api/stats/ports. The middleware returned before it looked
   at the host, so they served another host's counts, disk usage and published
   ports. Ungated means "no section required", not "any host you like": a named host
   must now be one the caller's grants reach somewhere. There's no single section to
   check against, hence the coarser Store.ReachableHosts.
2. List endpoints — hosts, projects, the alert feed and the audit log named
   hosts and workloads the caller was scoped away from. All four filter now, through
   one shared predicate. The alert feed's unread count is computed after
   filtering; a badge that still counted hidden events would announce them.
3. Metrics history was the one real gap. The store keys by container id, so
   knowing an id was enough to read its CPU/memory series from any host.
   ContainerStat already carried HostID and recordHistory was throwing it
   away — the sample keeps it now and the series is authorised against it. An
   unrecorded id is treated as unknown, not local, so ids can't be probed for
   existence.

Running it end to end found a bug phase 2 shipped

The local daemon can be named two ways: ?host=0 ("the default"), or the id of
the seeded kind = 'local' row (usually 1). Only 0 was treated as
always-in-scope. So a scoped user kept ?host=0 but was denied ?host=1, and
the local host vanished from their host list. Both names normalise to the same
daemon now.

The unit tests missed it because they only ever used 0.
TestHostScope_LocalHostIsInScopeUnderEitherID uses both and fails on the old code.

Verification

Every fix was mutation-tested — removing the ungated-route check, the filter
predicate, the post-filter unread count, or the metrics host check each fails its
own test and nothing else's.

End to end, a user scoped to staging:

	admin	dev (scoped)
host list	local, prod, staging	local, staging
/api/stats/overview?host=prod	200/502	403
/api/containers?host=0 / ?host=1	ok	both 200
/api/containers?host=prod	ok	403

What's deliberately left

The alert engine still watches every host — it's background work with no user
context. So a rule that names you as an e-mail recipient can mail you about a host
you can't see in the app. That's a property of how recipients are configured, not
something the app can decide per viewer, and it's documented in docs/users.md
rather than implied away.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.