Postgres partitioning enhancements: sub-partitioning + tablespace on partitioned parents

[ihistand]

Remaining native-partitioning gaps (cli/api/dbadapters/postgres_execution_sql.ts createPartitionedTableTasks):

• Sub-partitioning (nested PARTITION BY) — not supported.
• Tablespace on the partitioned parent — createPartitionedTableTasks omits it (the regular createTable applies it). Minor.

Not gaps (confirmed): indexes + opclass on partitioned tables already work (createIndexes runs for the partitioned path). fillfactor on a partitioned parent is invalid — Postgres forbids storage params on partitioned tables. Split from #15.

[ihistand]

Implemented and merged to main (c3004944, fast-forward). Both gaps in createPartitionedTableTasks closed:

Tablespace on the partitioned parent — postgres.tablespace is now applied to the parent CREATE TABLE (after the PARTITION BY clause, per Postgres syntax). On a partitioned parent this sets the default placement inherited by child partitions (the parent stores no rows itself).

Sub-partitioning (nested PARTITION BY) — added a recursive proto field PostgresOptions.Partition.Bound.sub_partition. A child bound carrying a sub_partition becomes a partitioned table in its own right (… PARTITION BY <kind> (<cols>)) and recurses to create its sub-partitions; a leaf child holds rows directly. The single INSERT into the parent cascades through every level of the hierarchy, so only the leaf partitions need to exist beforehand.

Config flows through automatically — PostgresOptions.create(config.postgres) carries the nested structure with no hand-written mapping.

Tests (cli/api/execution_sql_test.ts, TDD): two new SQL-generation cases — (1) the partitioned parent emits … partition by range ("id") tablespace "fast_ssd", and (2) a sub-partitioned child emits … for values … partition by list ("field1") plus its grandchild …__p0__us. Both RED before, GREEN after; the existing single-level partition test is unchanged (backward compatible).

Verification — ./scripts/docker-bazel test //core/... //cli/api/... → all 26 targets PASS.

Note: SQL-generation is unit-verified here. A live-PG integration case (asserting rows route through the sub-partition hierarchy on real Postgres, alongside the existing postgres.spec partitioning test) is a reasonable follow-up but not required for this change. The third historical nice-to-have — opclasses on partitioned indexes — is out of scope here.

Closing as completed.