Preserve REST v1 through the shared tuning boundary

[sebawebber]

Parent

#43

What to build

Move REST v1 onto the shared tuning operation while preserving its established
public contract. REST clients should observe no change, but the API should no
longer maintain a separate route into the tuning calculations.

Acceptance criteria

• REST v1 obtains recommendations through the shared tuning boundary rather than invoking the legacy calculation pipeline directly.
• Existing REST v1 request fields, defaults, validation behavior, status codes, and response shapes remain unchanged.
• Existing REST v1 output formats and documentation enrichment remain unchanged.
• REST v1 continues to return legacy compatibility recommendations, including listen_addresses, even though MCP omits it.
• Regression tests compare representative REST v1 responses before and after the migration.
• Existing REST v1 tests and the complete Go test suite remain green.

Blocked by

• Establish the provenance-aware tuning boundary #44