feat(logs): derive default log sources from agent capabilities

[sarg3nt]

Summary

• APILogSourcesHandler returned a hardcoded [haproxy, system] pair whenever no per-box settings existed. On a box whose agent has no logs or access-log gear (e.g. Mjolnir's distroless container agent), the Logs page would load both defaults and then fail every fetch against the agent that has nothing to serve. Combined with the plain-text 5xx responses (fixed in sibling PR fix(errors): emit JSON envelope from WriteHTTPError + harden fetch callers #114), this produced the visible Error loading logs: Unexpected token 'F' toast.
• Drive the no-settings default off the agent's probe table:
  • haproxy offered when either access-log or logs gear is available
  • system offered only when logs gear is available
  • Empty list when the agent advertises a probe table but neither log gear is available — JS renders an empty dropdown and skips the fetch
  • Fail-open: if capabilities aren't reachable at all, fall back to legacy [haproxy, system] so deployments work through transient outages
• All existing call sites (api_logs.go::APILogsHandler, services page, logs page) continue to work — the resolver is internal.

Phase 2 slice of #112.

Test plan

• go build ./... and go vet ./... clean
• go test -count=1 ./internal/framework/handler/... clean
• On Mjolnir (agent with only access-log/host/metrics available), navigate to /logs?server=mjolnir and confirm the source dropdown shows only HAProxy (no System) and the page loads access-log content cleanly.
• On light-hugger (logs available), confirm both HAProxy and System appear in the dropdown — backwards compatible.
• Stop the agent temporarily, reload /logs — confirm the legacy fallback kicks in and the page degrades gracefully.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the dashboard’s Logs API to derive the default log-source dropdown entries from the selected box’s agent capability/probe table, instead of always defaulting to the legacy haproxy + system pair when no per-box settings exist. This supports the broader “capability-driven autoconfig” effort so the Logs page doesn’t immediately issue requests for log gears the agent cannot serve.

Changes:

• Replace the hardcoded no-settings default in APILogSourcesHandler with a capability-driven default resolver.
• Add defaultLogSourcesForBox, which selects haproxy and/or system based on the agent’s access-log / logs gear availability, with a fail-open fallback when capabilities cannot be fetched.

Comments suppressed due to low confidence (1)

gearbox/internal/framework/handler/api_logs.go:140

• Returning an empty sources list here assumes the frontend will preserve the empty dropdown and skip the initial log fetch, but the current Logs page JS treats sources.length === 0 as a failure and falls back to the legacy defaults, which would reintroduce the bad fetches on boxes without log gears. Either adjust the API contract so callers can distinguish "no sources available" from "error" (and update the JS accordingly), or avoid returning an empty list until the frontend handling is in place.

	if !hasAccessLog && !hasLogs {
		// Agent surfaces a probe table but neither log gear is available.
		// Returning the empty list lets the JS render an empty dropdown
		// and skip the immediate fetch — better than 5xx storming.
		return []map[string]string{}