perf(core): Deep dive optimizations for hot path

[cofin]

This PR implements deep dive optimizations identified in the core-hotpath-opt flow.

Key Changes

• Query Cache (_qc_*): LRU cache for prepared statements - bypasses SQL parsing and parameter transformation on repeated queries
• Micro-caching: Single-slot cache in SQLProcessor to bypass dictionary lookups for repeated queries
• String Fast Paths: Internal SQL object caching for raw string statements in prepare_statement
• Parameter Optimization: Optimized SQL.copy to fast-track parameter updates and streamlined parameter fingerprinting
• Observability: Added is_idle check to bypass expensive instrumentation overhead when disabled
• Result Construction: Optimized ExecutionResult creation and metadata handling

Benchmark Results (10k rows, sqlite)

┏━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┓
┃ Driver ┃ Library    ┃ Scenario          ┃ Time (s) ┃ % Slower vs Raw ┃
┡━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━┩
│ sqlite │ raw        │ initialization    │   0.0018 │               — │
│ sqlite │ sqlspec    │ initialization    │   0.0035 │           98.2% │
│ sqlite │ sqlalchemy │ initialization    │   0.0852 │         4694.1% │
│ sqlite │ raw        │ write_heavy       │   0.0817 │               — │
│ sqlite │ sqlspec    │ write_heavy       │   0.0773 │           -5.4% │
│ sqlite │ sqlalchemy │ write_heavy       │   0.0493 │          -39.6% │
│ sqlite │ raw        │ read_heavy        │   0.0238 │               — │
│ sqlite │ sqlspec    │ read_heavy        │   0.0393 │           65.1% │
│ sqlite │ sqlalchemy │ read_heavy        │   0.0346 │           45.6% │
│ sqlite │ raw        │ iterative_inserts │   0.0188 │               — │
│ sqlite │ sqlspec    │ iterative_inserts │   0.2947 │         1465.1% │
│ sqlite │ sqlalchemy │ iterative_inserts │   0.4270 │         2167.7% │
│ sqlite │ raw        │ repeated_queries  │   9.1935 │               — │
│ sqlite │ sqlspec    │ repeated_queries  │   9.3915 │            2.2% │
│ sqlite │ sqlalchemy │ repeated_queries  │   9.9289 │            8.0% │
└────────┴────────────┴───────────────────┴──────────┴─────────────────┘

How to interpret these results

Scenario	What it tests	sqlspec	sqlalchemy
write_heavy	Bulk insert via execute_many	-5% (faster!)	-40%
read_heavy	Bulk read via fetchall	+65%	+46%
iterative_inserts	Individual inserts in a loop	+1465%	+2167%
repeated_queries	Same SELECT with varying params	+2.2%	+8.0%

Key insight: The repeated_queries scenario shows the query cache in action. When the same SQL statement is executed repeatedly with different parameters:

1. First execution: Full parsing, parameter transformation, and statement preparation
2. Subsequent executions: Cache hit → skip parsing → directly bind new parameters

This reduces sqlspec's overhead from ~1500% (iterative inserts) to just ~2% (repeated queries).

Why iterative_inserts is slow

Each call to session.execute() must:

• Parse the SQL string
• Transform parameters to native format
• Build the Statement object
• Execute and build result

For bulk operations, use execute_many() which amortizes this cost across all rows.

Benchmark Tooling

Added scripts/bench.py (originally from @euri10's PR #354) with enhancements:

uv run python scripts/bench.py --driver sqlite --rows 10000

Scenarios:

• initialization - Connection and table setup overhead
• write_heavy - Bulk insert via execute_many
• read_heavy - Bulk insert + fetchall
• iterative_inserts - Individual execute calls in a loop
• repeated_queries - Single-row queries with varying params (tests query cache)