feat(optimize): KRR right-sizing via cluster analysis when observability is on

[Guimove]

Why

qovery-optimize right-sizes services by hand: PromQL queries against the metrics API, then peak-times-buffer formulas. Qovery now ships a first-class KRR integration ('qovery cluster analysis cost-recommendation', engine-side), which produces better numbers than the formulas: P99 percentiles, max-based limits, and OOMKill history so a container that already OOMKilled never gets under-provisioned. The skill did not use it. This PR makes KRR the right-sizing source whenever the cluster has Qovery observability enabled, with the formulas kept as fallback.

What

• New reference 'phase2b-krr-rightsizing.md': precondition check ('metrics_parameters.enabled' on the cluster), the analysis command with the Qovery-proven flag set (P99 CPU request/limit, 15% memory buffer, OOMKill-aware with 25% extra, --allow-hpa, timeframe matched to the Phase 1 analysis period), report retrieval ('qovery cluster analysis logs'), mapping rows back to Qovery services, and the fallback path.
• Phase 1.3 now checks observability first and routes right-sizing to Phase 2b when enabled; the metrics API queries remain the source for the other dimensions.
• Phase 2 Dimension 1 states the formulas are the fallback; the business-context guardrails (minimum thresholds, seasonal peaks, growth buffers) apply to both paths.
• SKILL.md: description mentions KRR (so 'run KRR' prompts route here), Phase 2b navigation row, analysis commands in the CLI quick reference, KRR link.
• New eval scenario covering the observability-enabled path.

Design choices

• CLI analysis, not a local KRR run. The engine runs KRR server-side against the cluster's metrics stack: read-only, no kubeconfig, no port-forward, no local install, and '--cmd-arg' values are allowlisted and validated by the engine. A hand-run KRR would need all of that plus tunnel handling.
• KRR replaces the measurement, not the judgment. Guardrails stay on top: never below 50m/128MB, never below a seasonal peak the timeframe missed, growth buffers preserved, changes applied only after per-service confirmation (Phase 4 unchanged).
• Explicit fallback. Observability off with no user Prometheus, or CLI too old: the skill falls back to the existing Dimension 1 formulas and tags report rows as formula-based instead of KRR-based, so reports always state their source.

Test plan

• SKILL.md at 173 lines (under 500)
• All internal reference links resolve
• No anti-patterns (2nd-person openers, time-sensitive content, AI trailers)
• evals/qovery-optimize.json valid, existing scenarios untouched (style-preserving edit, no reformat)
• curl example in the new reference carries the User-Agent header per CLAUDE.md
• CLI flags cross-checked against qovery-cli source (cluster_analysis*.go): command names, --cmd-arg format, --watch/--output/--no-logs behavior

Reviewer notes

• The flag set mirrors the one documented in the internal KRR report workflow (P99 + OOM buffers); the CSV output can still be dropped into the KRR Report Generator for a client-facing HTML report.
• The reference avoids naming exact REST paths for the analysis API (CLI is the documented interface); if you prefer the raw endpoints documented too, say so and I'll add them.