feat: implement strict mode for max_records_per_run to prevent offset overshoot with composite keys

[halconel]

Summary

Implements strict mode for max_records_per_run to fix offset overshoot bug when using composite keys. When max_records_per_run limits the batch size, the offset calculation now uses only the actually processed records instead of all events for the processed key pairs.

Problem

When transform_keys differ from the input table's primary key:

• SQL query with LIMIT returns N specific records with full PK
• These records group by transform_keys into fewer pairs
• get_batch_input_dfs reads ALL events for those pairs (not just N records)
• Offset = MAX(update_ts) from all events → overshoot beyond the limited batch
• Result: intermediate data gets skipped in subsequent runs

Solution

Strict mode behavior when max_records_per_run is set:

1. SQL query includes full PK in result (via _get_additional_idx_columns)
2. Result wrapped in IndexDFWithMetadata(idx_grouped, changed_idx_full_pk)
3. get_batch_input_dfs reads ONLY the specific records from changed_idx (strict mode)
4. Offset calculated from changed_idx instead of querying DB
5. Removed limit_hit guard - safe to update offset with strict mode

Changes

• New file: datapipe/index_metadata.py - wrapper class for passing metadata with idx
• Modified: datapipe/step/batch_transform.py - strict mode implementation
• New test: tests/test_overshoot_composite_keys.py - demonstrates bug and verifies fix
• Updated: tests/test_batch_transform_with_offset_optimization.py - updated for strict mode behavior
• Documentation: docs/max_records_per_run_associativity_plan.md - implementation plan