Add vMCP Serve skeleton and ServerConfig

[tgrunnagle]

Summary

This is the transport-side entry point of the New/Serve split that the rest of
the vMCP Phase 2 refactor (epic #5419) builds on. Today server.New is a
god-object that constructs both the identity-parameterized core domain logic and
the HTTP/SDK transport in one call. This PR lands the additive Serve skeleton so
later tasks can relocate the remaining transport concerns onto it without churning
server.New.

• Add Serve(ctx, core.VMCP, *ServerConfig) (*Server, error) in the new
  pkg/vmcp/server/serve.go. Serve wraps an already-constructed core VMCP and
  returns the existing *Server struct, so all carried-forward accessors
  (Handler/Start/Stop/Address/MCPServer/Ready) keep working unchanged.
• Add the transport-only ServerConfig struct — the subset of the legacy
  server.Config that configures the HTTP/SDK runtime, plus the cross-cutting
  TelemetryProvider/AuditConfig consumed by both the core and the transport.
• Serve applies the same transport defaults server.New applies today
  (Host → 127.0.0.1, EndpointPath → /mcp, Name/Version/SessionTTL
  defaults; Port == 0 stays "OS-assigned"), builds the mcp-go server, and wires
  the core's Close into the server's shutdown sequence.
• Guard the /status handler against a nil backend registry, since the transport
  does not yet own the registry at this phase.

server.New is intentionally not routed through Serve in this PR, so the
change is purely additive and observable behavior is unchanged. This keeps the PR
small and the parity surface flat; Phase 3 (#5444/#5445) reduces server.New to a
wrapper over Serve.

Stacked PR. This branch is stacked on #5459 (admission seam, Closes #5438),
which is itself stacked on the New/VMCP work (#5437). It should target the
parent branch vmcp-core-p1-5_issue_5438 for review, not main. The
pkg/vmcp/core/* changes visible in a diff against main are inherited from
those upstream PRs and are not part of this change. The only files this PR
introduces are pkg/vmcp/server/serve.go, pkg/vmcp/server/serve_test.go, and
the pkg/vmcp/server/status.go nil-registry guard.

Closes #5439

Type of change

• Refactoring (no behavior change)

Test plan

• Unit tests (task test)
• Linting (task lint-fix)

Added pkg/vmcp/server/serve_test.go covering:

• Serve applies transport defaults identically to server.New and leaves the
  caller's ServerConfig unmutated and Port == 0 OS-assigned.
• Serve preserves explicitly set config values.
• The returned *Server exposes a usable MCPServer(), and Handler(ctx)
  registers the unauthenticated routes (/health, /ping, /readyz, /status,
  /api/backends/health); /metrics is absent without a telemetry provider.
• Stop runs the shutdown funcs and closes the injected core.
• Validation returns a vmcp.ErrInvalidConfig-wrapped error for nil cfg, nil
  core, and nil SessionFactory.
• A reflection-based drift guard asserts every Config field is populated by
  buildServeConfig except the documented intentionally-unmapped set
  (AuthzMiddleware, HealthMonitorConfig).

The existing server.New-driven behavioral-parity suite stays green; server.New
is untouched and not routed through Serve. Repo-wide lint is clean apart from a
pre-existing, unrelated gosec G115 finding in cmd/thv/app/upgrade.go.

Changes

File	Change
pkg/vmcp/server/serve.go	New Serve entry point and transport-only ServerConfig; buildServeConfig maps config and applies defaults
pkg/vmcp/server/serve_test.go	Unit tests for defaults, config preservation, route registration, shutdown wiring, validation, and mapping drift
pkg/vmcp/server/status.go	Nil-registry guard in buildStatusResponse so the Serve skeleton returns an empty backend view instead of panicking

Does this introduce a user-facing change?

No.

Special notes for reviewers

• Relocate, don't rewrite. Serve returns the same *Server struct rather
  than a new type, and mirrors the defaults and mcp-go construction that
  server.New performs today. No mcp-go types cross the VMCP boundary.
• Why ServerConfig exists. These fields configure the HTTP/SDK runtime and
  are meaningless to the core (R3). The stutter server.ServerConfig is
  intentional and nolint-annotated: the split mandates the name and the package's
  existing Config is the legacy type being decomposed.
• Deferred follow-ups. SDK session hooks and two-phase creation (P2.2 Move SDK hooks + two-phase session creation under Serve #5440), the
  authenticated middleware chain and direct VMCP request path (P2.3 Move middleware chain under Serve; remove authz + annotation mw #5441), and the AS
  runner / status reporter / optimizer / health monitor lifecycle (P2.5 Move AS runner, status reporter, optimizer, health monitor under Serve #5443) are moved
  under Serve by later Phase 2 tasks. The buildServeConfig drift-guard test
  documents the two fields deliberately unmapped until then.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.25%. Comparing base (d048950) to head (3d5e331).

Additional details and impacted files

@@                      Coverage Diff                      @@
##           vmcp-core-p1-5_issue_5438    #5467      +/-   ##
=============================================================
+ Coverage                      69.23%   69.25%   +0.02%     
=============================================================
  Files                            637      638       +1     
  Lines                          64859    64909      +50     
=============================================================
+ Hits                           44907    44955      +48     
- Misses                         16629    16633       +4     
+ Partials                        3323     3321       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tgrunnagle]

Multi-agent review — Serve skeleton + ServerConfig

Sound, behavior-preserving additive skeleton. The deferral of the route mux/lifecycle to the carried-forward Handler/Start/Stop (rather than rebuilding it in Serve) is the correct design call and faithful to the epic's "relocate, don't rewrite" principle — not a scope gap. Tests pass; clean boundary (no mcp-go types cross core.VMCP); buildServeConfig copies-before-mutating (better than New).

No HIGH findings — nothing blocks merge. The MEDIUM items are about tightening the parity-drift protection this staged refactor leans on, plus a couple of test/comment-precision gaps.

Severity	Finding
MEDIUM	Default literals triplicated (New / buildServeConfig / test) + drift guard checks presence, not value/inverse
MEDIUM	Dead Config.StatusReporter mapping — set directly on the struct, mapped only to satisfy the drift test
MEDIUM	.well-known/ route in the AC but untested; "auth-chain absent" comment overstates reality (Handler still builds the chain)
LOW-MED	Serve-built *Server is not startable (nil session/discovery/registry); document the nil-field contract
LOW	nil-registry guard may silently mask a real misconfig on the server.New path

Minor (non-blocking, no inline comment): no positive /metrics-registered assertion; Close idempotency and a combined nil-cfg+nil-vmcp ordering case aren't asserted.

Reviewed by 4 specialist agents (correctness, architecture, test, security). Codex cross-review skipped (CLI not installed).

🤖 Generated with Claude Code

[tgrunnagle]

Re: the non-blocking minor items in the review body (addressed in 3d5e331):

• Positive /metrics assertion — added TestServeHandlerRegistersMetricsWhenTelemetryEnabled, which builds a real telemetry.Provider with EnablePrometheusMetricsPath: true and asserts /metrics returns 200.
• Combined nil-cfg + nil-vmcp ordering — added a nil config and nil vmcp case to TestServeValidation, confirming it fails cleanly (cfg is checked first; no nil-deref).
• Close idempotency — left as-is: idempotency is a contract of real core.VMCP implementations, not of Serve's wiring. Serve appends exactly one Close to shutdownFuncs, which TestServeStopClosesCore already verifies. Happy to add a count-based assertion if you'd prefer it pinned.