Add upgrade-check REST endpoints for workloads (#5408)

* Add upgrade detection for registry workloads

CLI and API users have no way to discover when a newer version of a
registry-sourced MCP server is available; only Studio implements drift
detection, in its frontend. Introduce a backend package that all clients
can consume.

Add pkg/workloads/upgrade with a Checker that compares a running
workload's image tag against its registry entry (semver-aware, with a
string fallback) and reports environment-variable and configuration
(transport / permission-profile / network-isolation) drift. Comparison
degrades safely to "unknown" for :latest, digest refs, repository
changes, and non-registry-sourced workloads, so only a strictly-newer
tag on the same repository yields "upgrade-available".

This is the read-only detection core (RFC THV-0068, phase A); the apply
path, API endpoints, and CLI follow in later changes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Address review feedback on upgrade detection

- Lowercase an uppercase "V" tag prefix so semver comparison works;
  "V1.2.0" vs "V1.3.0" no longer falls through to undecidable and
  hides a real upgrade.
- Drop the raw provider error from CheckResult.Reason (it is serialized
  into the API response and can leak internal addressing); log it at
  DEBUG and return a fixed string. Same for the CheckAll path.
- Add a defensive default to the comparison switch so an unexpected
  value yields StatusUnknown rather than the least-safe StatusUpToDate.
- Stop reporting network-isolation drift: the registry has no
  network-isolation field, so it fired for every isolated workload
  regardless of the candidate version. Remove the ConfigDrift field
  and the now-unused BoolChange type.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Add upgrade-check REST endpoints for workloads

CLI, Studio, and automation need a single backend source of truth for
upgrade availability instead of each client reimplementing registry
drift detection. Expose the Phase A checker over the existing workloads
API.

Add GET /api/v1beta/workloads/upgrade-check (batch) and
GET /api/v1beta/workloads/{name}/upgrade-check (single). The batch
handler reuses the exact group/all authorization scoping of the list
endpoint and intersects it with the enumerated run configs, so it can
never report a workload outside the caller's scope. Responses carry only
non-sensitive CheckResult metadata; secret env-var defaults are cleared.
Both routes are read-only and skip image pulls, so they use the standard
timeout. Regenerate the OpenAPI spec.

The dedicated apply endpoint (POST .../upgrade) follows once the Applier
lands (RFC THV-0068, phase B).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Return 404 for unknown group in workload listing

FilterByGroup returns an empty slice (nil error) for a group that does
not exist, so a typo'd ?group= silently returned 200 with an empty list
instead of the documented 404. Check group existence explicitly via the
group manager before filtering, in both the upgrade-check and the
listWorkloads handlers, so the advertised 404 is real. Add a bulk
upgrade-check test covering the unknown-group path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Regenerate OpenAPI spec after dropping network-isolation drift

The upgrade detection change removed the ConfigDrift.NetworkIsolation
field and the BoolChange type, so regenerate the committed OpenAPI spec
to drop the stale schema and property. Fixes the Verify Swagger
Documentation CI check.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: JAORMX