Add StatusReporter abstraction for vMCP runtime status reporting

[yrobla]

Implement platform-agnostic StatusReporter interface to enable vMCP runtime to report operational status. This is the foundation for eliminating duplicate backend discovery work between the operator and vMCP runtime.

Closes: #3147

[Copilot]

Pull request overview

This PR introduces a platform-agnostic StatusReporter abstraction that enables the vMCP runtime to report operational status. The implementation provides a foundation for eliminating duplicate backend discovery work between the operator and vMCP runtime by allowing the runtime to directly communicate its state.

Changes:

• Added StatusReporter interface and RuntimeStatus types with comprehensive status model
• Implemented NoOpReporter for CLI/local development environments
• Integrated StatusReporter into vMCP server with lifecycle management
• Provided comprehensive documentation and test coverage

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pkg/vmcp/status/types.go	Defines RuntimeStatus data model with Phase, Condition, and DiscoveredBackend types following Kubernetes conventions
pkg/vmcp/status/reporter.go	Declares platform-agnostic Reporter interface with Report, Start, and Stop methods
pkg/vmcp/status/noop_reporter.go	Implements no-operation reporter for CLI/local development environments
pkg/vmcp/status/noop_reporter_test.go	Provides comprehensive test coverage including edge cases and concurrency tests
pkg/vmcp/status/README.md	Documents architecture, design principles, usage patterns, and future implementations
pkg/vmcp/server/server.go	Integrates StatusReporter field and lifecycle management in Start/Stop methods
cmd/vmcp/app/commands.go	Initializes NoOpReporter for CLI mode in server configuration

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 56.96%. Comparing base (51b37e3) to head (e520544).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/vmcp/server/server.go	16.66%	3 Missing and 2 partials ⚠️
cmd/vmcp/app/commands.go	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3250      +/-   ##
==========================================
- Coverage   56.97%   56.96%   -0.02%     
==========================================
  Files         351      352       +1     
  Lines       34962    34978      +16     
==========================================
+ Hits        19919    19924       +5     
- Misses      13387    13396       +9     
- Partials     1656     1658       +2     

☔ View full report in Codecov by Sentry.
📢 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.

[jhrozek]

Good implementation of the StatusReporter abstraction. The interface design and NoOpReporter implementation look solid. A few observations and questions below.

[jhrozek]

Observation: ToolHive typically doesn't include package-level README.md files. Most packages use doc.go for package documentation instead.

Looking at pkg/, this is one of only two READMEs (the other being in testdata). Consider whether this 299-line README could be trimmed down to essential usage info in doc.go comments, or if there's a strong reason to keep it as a README.

Not blocking, just flagging for consistency with the rest of the codebase.

[jhrozek]

Question about lifecycle: The reporter's Start() method is not called here (just a debug log), but Stop() IS called during shutdown (line 655).

This asymmetric lifecycle works fine for NoOpReporter, but could be confusing when implementing a real reporter like K8sReporter - someone might forget to add the Start() call.

Is there a plan to complete this integration, or is it intentionally deferred? If deferred, consider adding a reference to a follow-up issue in the TODO comment.

[jhrozek]

Question about statusFunc: When periodic status reporting is implemented, will the statusFunc callback share logic with buildStatusResponse() (used by the /status HTTP endpoint)?

Asking to ensure consistency - both sources of status should report the same data to avoid confusion during debugging.