feat: Execute standalone extension statements in local runner

[WellMafra]

What was done

• DatasqrlRun.initPostgres now executes the plan's standaloneExtensionStatements (e.g. the pg_partman CREATE EXTENSION + create_parent block) after the regular statements, non-fatally: a failure logs a warning and the run continues, so a Postgres without the extension behaves exactly as before.
• Install postgresql-${POSTGRES_VERSION}-partman in the sqrl-cli base image so run/test can actually create the extension locally.

Why it was done

• Tables with a ttl() hint are emitted as PARTITION BY RANGE parents with no inline default partition (pg_partman owns their lifecycle), but the local runner never executed the partman block — leaving the parent with zero partitions, so every insert fails with no partition of relation ... found for row. This made sqrl test/sqrl run unusable for any project using ttl() on a Postgres table.
• Validated end-to-end against DataSQRL/cloud-backend metrics: with this image the runner logs Executing standalone extension statement partman of type EXTENSION, historical test fixtures land in the partman DEFAULT partition, and all 14 snapshot tests pass.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 18.90%. Comparing base (ea2cf01) to head (2f4bdf2).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2279      +/-   ##
============================================
+ Coverage     18.78%   18.90%   +0.11%     
- Complexity     1223     1227       +4     
============================================
  Files           630      630              
  Lines         18409    18420      +11     
  Branches       2250     2251       +1     
============================================
+ Hits           3459     3483      +24     
+ Misses        14618    14605      -13     
  Partials        332      332              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[ferenc-csaky]

Why executing standaloneExtensionStatements AFTER the regular statements? I would consider an extension setup more general than a CREATE TABLE, so in an initialization phase, I'd rather execute standaloneExtensionStatements first.

[WellMafra]

Why executing standaloneExtensionStatements AFTER the regular statements?

because the create_parent requires the parent table to already exist.