feat: add per-pool slippage, utilization, and execution risk to /simulate response

[0xcentur1on]

Summary

Enriches each pool entry in the /simulate response with three new fields that give callers a complete, server-side view of execution risk before sending a transaction on-chain:

• slippage_bps — per-ladder-step price impact in basis points (positive = cost to trader)
• pool_utilization_bps — fraction of the pool's reported max_in consumed by the largest requested amount (10 000 = 100 %)
• execution_risk — composite risk score and qualitative label (low / medium / high / very_high / unknown) derived from slippage, utilization, curve convexity, and ladder completeness

A new pool_type field (blue_chip | stablecoin | volatile, defaults to volatile) on the request lets callers pass pool-class context so the service can apply pool-type-aware weights when computing the risk score.

Changed files

File	What changed
src/models/messages.rs	Added PoolType enum, pool_type on AmountOutRequest; added slippage_bps, pool_utilization_bps, execution_risk on AmountOutResponse; added ExecutionRisk struct and RiskLevel enum; added SkippedPrecheck pool outcome kind
src/services/quotes.rs	Implemented compute_slippage_bps, compute_pool_utilization_bps, and compute_execution_risk (pool-type-aware weights); extended PoolQuoteResult with spot_price and max_in; wires all three new fields into response construction
src/handlers/quote.rs	Updated SkippedPrecheck arm
src/sim_analysis/mod.rs	Code cleanup
docs/slippage.md	New — explains the per-step slippage calculation strategy
docs/pool-execution-risk.md	New — documents the risk score formula, weights, and risk-level thresholds
docs/tycho-simulation-library.md	New — reference notes on the Tycho simulation library API used here
scripts/start_server.sh	Optimises binary selection for local dev environments
.gitignore	Added Cargo temp file patterns

Risk score formula

risk_score = w1 × slippage_last_bps
           + w2 × utilization_bps
           + w3 × convexity_ratio   (slippage_last / slippage_first)
           + w4 × partial_ladder × 10_000

Weights differ by pool type (blue-chip pools apply tighter slippage tolerance; stablecoin pools penalise utilization more heavily). Block-lag staleness is excluded from the server-side score — callers should add that penalty using block_number vs. the current chain head.

Risk level	Score range	Interpretation
low	< 200	Deep pool; minimal sensitivity to concurrent activity
medium	200 – 499	Moderate sensitivity; suitable for most orders
high	500 – 999	Pool state sensitive to competing routing
very_high	≥ 1 000	Prefer splitting across multiple pools
unknown	—	Insufficient signal (all slippage null and no utilization)

Test plan

• cargo test passes (216 tests: 182 unit + 32 integration + 2 main)
• slippage_bps, pool_utilization_bps, and execution_risk appear in /simulate pool responses
• execution_risk is omitted from the response when insufficient signal is available
• Backward-compatible: pool_type defaults to volatile; new fields skip serialisation when absent

Closes #45