Global track values are redundantly recomputed for every file during import

[TimGels]

Problem

When importing a batch of files, the global track values (language, name, default flag, forced flag) are recomputed after each individual file is processed. Only the final computation — when all files are present — produces the correct result. All previous computations are thrown away.

For a batch of N files, this means the global values are computed N times (reading 1, 2, 3, ... N file configs respectively), when computing them once at the end would be sufficient.

This is O(N²) work where O(N) would suffice.

Edge cases to consider

• Adding files to an existing batch: If 5 files are already loaded and 3 more are added, the global values should be recomputed once across all 8 files — not incrementally 3 times during the add.
• Removing files: After removing files, the global values still reflect the removed files' data until the next import triggers recomputation. Global values should be recalculated when files are removed.
• Single file import: No redundancy in this case, but the solution should handle it uniformly.

Expected behavior

Per-file track configuration should be initialized for all files first, then global values should be computed once with the complete set of file data. This should apply consistently across import, removal, and revalidation flows.

[TimGels]

Current state on refactor/track-intent-architecture / PR #91:

• Import correctness is fixed: imported files are now added to the batch before InitializeTrackConfigStage runs, so aggregate defaults see the full imported set during the same import.
• The redundancy described in this issue is still present: InitializeTrackConfigStage still iterates the scanned files and calls the aggregate rule engine once per file, even though those rules now derive from the whole batch. So the final result is correct, but aggregate values are still recomputed N times during an N-file import.
• The removal/revalidation part is also still unresolved: the remove path updates FileList, and revalidation runs validation, but neither path recomputes the global track values for the remaining batch unless the batch becomes empty.

So I would treat this as partially addressed, not closed.

The remaining fix is to separate:

• structural expansion of track slots
• aggregate derivation of global track values

Then run the aggregate derivation once after add/remove/refresh/revalidate flows instead of once per scanned file.