feat: Extract sqrl-planner-model module for plan file model classes

[velo]

Why

Consumers that only need to read or write DataSQRL's output files (postgres.json, kafka.json, flink.json, pipeline_mutation_database.json) currently have to depend on sqrl-planner, which drags in Calcite, Flink and the whole compiler. This extracts those model classes into a new module whose only dependencies are jackson-annotations and jackson-databind (plus provided Lombok).

What

New sqrl-planner-model module, packages unchanged so nothing else had to re-import:

• EnginePhysicalPlan + DeploymentArtifact / ArtifactType — the Flink-only toYamlString helper moved to FlinkPhysicalPlan, its sole caller
• JdbcPlan (new) — the JDBC plan files, with getStatementsForType and the schema/views artifact logic
• JdbcStatement, GenericJdbcStatement, CreateTableJdbcStatement
• KafkaPhysicalPlan + NewTopic
• FlinkPlan (new)
• MutationDatabase + nested Table / TableDefinition / ColumnDefinition
• CombinedEnginePlan, StreamPhysicalPlan, DatabasePhysicalPlan, EngineCreateTable

How the entangled classes were split

FlinkPhysicalPlan and JdbcPhysicalPlan stay in the planner — they carry RelNode / Configuration working state — but now serialize through @JsonValue toModel() delegating to FlinkPlan / JdbcPlan. The model classes are the single source of truth for the file format, so the two cannot drift.

• GenericJdbcStatement lost a write-only RelDataType field
• CreateTableJdbcStatement.engineTable widened to the EngineCreateTable marker, with three casts at planner read sites
• MutationDatabase's planner-heavy statics moved to a new planner-side MutationDatabases helper
• ConfigLoaderUtils.loadPostgresPhysicalPlan now returns JdbcPlan

Not included

ServerPhysicalPlan content (the server-model.json shapes already live in the slim sqrl-server-core) and PostgresLogPhysicalPlan (its entries compute SQL from Calcite nodes at write time and are never deserialized).

Testing

New PlanModelSerializationTest pins the emitted field set for both plan types and round-trips postgres.json through JdbcPlan, guarding the file format against drift. Full reactor mvn test passes; snapshots are unaffected because the serialized JSON is byte-identical.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 60.41667% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 17.27%. Comparing base (ea69f32) to head (bdb1370).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...om/datasqrl/planner/dag/plan/MutationDatabase.java	0.00%	4 Missing ⚠️
...engine/database/relational/AbstractJDBCEngine.java	0.00%	2 Missing ⚠️
...l/engine/database/relational/JdbcPhysicalPlan.java	33.33%	2 Missing ⚠️
...n/java/com/datasqrl/planner/FlinkPhysicalPlan.java	33.33%	2 Missing ⚠️
.../java/com/datasqrl/compile/CompilationProcess.java	0.00%	1 Missing ⚠️
.../database/relational/CreateTableJdbcStatement.java	0.00%	1 Missing ⚠️
.../datasqrl/engine/database/relational/JdbcPlan.java	95.45%	0 Missing and 1 partial ⚠️
...m/datasqrl/engine/log/kafka/KafkaPhysicalPlan.java	0.00%	1 Missing ⚠️
...ain/java/com/datasqrl/engine/stream/FlinkPlan.java	0.00%	1 Missing ⚠️
...rc/main/java/com/datasqrl/engine/PhysicalPlan.java	0.00%	1 Missing ⚠️
... and 3 more

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2237      +/-   ##
============================================
+ Coverage     17.13%   17.27%   +0.13%     
- Complexity     1054     1065      +11     
============================================
  Files           613      616       +3     
  Lines         17802    17817      +15     
  Branches       2166     2168       +2     
============================================
+ Hits           3051     3078      +27     
+ Misses        14435    14421      -14     
- Partials        316      318       +2     

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

[velo]

Closing in favour of #2238, which does the same extraction and additionally fixes the postgres.json round-trip loss on CREATE TABLE metadata. I've left the parts of this approach I think are worth keeping as review comments over there.