Establish the provenance-aware tuning boundary

[sebastianwebber]

Parent

#43

What to build

Establish a provenance-aware tuning operation that accepts a canonical, explicit
Tuning Request and returns deterministic Tuning Recommendations while existing
public consumers continue to behave exactly as they do today. This is the
prefactor that gives MCP, REST v1, the CLI, and a future REST v2 one domain
boundary without creating a second calculation pipeline.

Acceptance criteria

• A valid canonical Tuning Request produces a result containing the normalized request and recommendations keyed by PostgreSQL parameter name.
• Every Tuning Recommendation contains its PostgreSQL-formatted value and a concise deterministic English reason.
• Reasons describe the final value and include any cap or later adjustment that changed the initial calculation.
• Repeating the same request with the same application version produces an identical result.
• Existing calculation behavior remains covered by regression tests and no public REST or CLI output changes.
• A compatibility projection remains available for legacy consumers while they are migrated in later tickets.
• The shared operation is the only new entry point for rich tuning results; no MCP-specific calculation path is introduced.

Blocked by

None — can start immediately.