Add multi-partition key support to database.partitioned module

[Copilot]

• Add PartitionConfig struct for individual partition key configuration
• Update PartitionedDatabaseConfig to add Partitions []PartitionConfig field (backward-compatible)
• Update PartitionedDatabase to normalize configs and expose multi-partition methods
• Add MultiPartitionManager interface with PartitionConfigs(), EnsurePartitionForKey(), SyncPartitionsForKey()
• Update db_create_partition step to support optional partitionKey field
• Update db_sync_partitions step to support optional partitionKey field
• Update storage plugin to parse partitions array from config
• Update schema to add partitions field and partitionKey to step schemas
• Add tests for all new functionality
• Fix MultiPartitionManager doc comment (no longer says "two or more entries only")
• Deep copy Tables slice in PartitionConfigs() to preserve encapsulation
• Add type-specific validation for database.partitioned in schema/validate.go (require either partitions[] with valid entries, or partitionKey+tables in single-partition mode)
• Add 12 new validation tests + 1 deep copy test

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Pull request overview

Adds multi-partition-key support to the database.partitioned module so one module instance can manage multiple independent partitioning schemes (e.g., tenant_id LIST and api_version RANGE) while keeping backward compatibility with existing single-partition configs.

Changes:

• Introduces PartitionConfig, Partitions []PartitionConfig, and MultiPartitionManager APIs in database.partitioned.
• Updates step.db_create_partition / step.db_sync_partitions to optionally target a specific partitionKey.
• Extends storage plugin parsing and schema documentation to support partitions[].

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
module/database_partitioned.go	Adds multi-partition config model, normalization, and new per-key partition/sync methods.
module/database_partitioned_test.go	Adds unit tests for multi-partition behavior and step dispatching.
module/pipeline_step_db_create_partition.go	Adds optional partitionKey routing to EnsurePartitionForKey.
module/pipeline_step_db_sync_partitions.go	Adds optional partitionKey routing to SyncPartitionsForKey.
plugins/storage/plugin.go	Parses partitions array into module config.
schema/module_schema.go	Updates module + step schema fields/descriptions for partitions[] and step partitionKey.

[Copilot]

By making partitionKey and tables non-required here, schema.ValidateConfig will no longer reject a database.partitioned module config that sets neither the legacy single-partition fields nor a non-empty partitions array. That invalid config will pass validation but later fail at runtime (e.g., EnsurePartition will error on an empty/invalid identifier). Consider adding explicit type-specific validation for database.partitioned in schema/validate.go (require either partitions with required fields per entry, or partitionKey+tables in single-partition mode).

[intel352]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Applied all three review comments in a52815a:

1. MultiPartitionManager doc comment — updated to say it's implemented by PartitionedDatabase and is primarily meaningful when multiple configs are configured, removing the incorrect "two or more entries" restriction.

2. Deep copy in PartitionConfigs() — now deep-copies the Tables slice for each config so callers cannot mutate internal state; added TestPartitionedDatabase_PartitionConfigs_DeepCopiesTables to verify this.

3. database.partitioned config validation — added a case "database.partitioned": block in schema/validate.go that enforces: in multi-partition mode (partitions is a non-empty array), each entry must have a non-empty partitionKey and a non-empty tables list; in single-partition mode (no partitions or empty array), partitionKey and tables are required. 11 new tests cover all branches.