Systems translator does not reject stocks named after engine-reserved identifiers

[bpowers]

Problem

The systems format translator (src/simlin-engine/src/systems/translate.rs) does not validate user stock names against engine-reserved identifiers like time, dt, initial_time, and final_time. A systems model declaring a stock with one of these names produces a datamodel project with conflicting variables -- the user's stock and the engine's built-in variable occupy the same namespace, leading to undefined or incorrect simulation behavior.

For example, a systems format model containing Stock time(0, 100) would be translated into a datamodel Project that has both a user-defined stock named time and the engine's implicit time variable, with no error or warning.

Why it matters

• Correctness: A model that happens to use a reserved name will silently produce wrong simulation results or fail in confusing ways during compilation/simulation.
• Developer experience: There is no diagnostic at the translation layer telling the user their variable name is invalid, making the root cause difficult to identify.
• Robustness: Other input paths (XMILE, MDL) may have their own handling, but the systems format translator has no such guard.

Component(s) affected

• simlin-engine -- specifically src/simlin-engine/src/systems/translate.rs

Possible approaches

1. Reject at translation time: Maintain a set of reserved identifiers and emit a diagnostic error when a stock (or flow/aux) name matches one.
2. Reject at the datamodel/model validation layer: Add a general-purpose check that applies regardless of input format, catching reserved name conflicts for all import paths.
3. Both: Validate early in the translator for a good error message, and also add a safety net in the shared validation layer.

Approach 2 or 3 is likely best, since the same problem could theoretically arise via any input path.

Context

Identified during review related to PR #436. This is a pre-existing issue in the translator, not specific to the CLI path added in that PR. Related but distinct from #438 (synthesized _max aux shadowing user variables).