Support multi-track upgrades per path #17

Summary

Add a multi-track mode that lets one run manage different CPython minor tracks per path (e.g., libraries stay on 3.12 while services move to 3.13), while keeping single-track behavior as the default.

Why

Enterprises often run multiple Python tracks simultaneously. Today the action forces a single track per run and bails out when multiple tracks are detected. A controlled multi-track mode would unblock those workflows without losing safeguards.

What needs to happen

• Introduce configuration (multi_track: true or similar) plus a way to map directories/globs to target tracks.
• Adjust detection to respect per-path track assignments and avoid the current multi-track guardrail when enabled.
• Update change matrix, branch naming, and PR copy to make the per-track upgrades clear.
• Add thorough tests covering multiple tracks, misconfigurations, and fallback to single-track safety.
• Document the feature and risks, emphasizing the default remains single-track.

References

• Roadmap policy/multi-track item: "Multi-track mode".

Acceptance criteria

• Users can declare multiple tracks and see separate updates applied per mapping.
• When disabled, current safety checks remain unchanged.
• Tests and docs explain configuration and expected outputs.