feat: add time-aware EDM support and realistic animations (fixes #406)

[deveshbervar]

• Add EventTime and EventMetadata interfaces to event-data-loader.ts
• Add optional getEventTime?() to EventDataLoader interface
• Extract event-level time (ns) in PhoenixLoader.buildEventData()
• Forward event time to AnimationsManager
• Add setEventTime(), getTimeProgress(), update() to AnimationsManager
• Add Event Time Progress slider to dat-gui UI
• Add tests for time extraction in phoenix-loader.test.ts

[EdwardMoyse]

Hi @deveshbervar - sorry for taking so long to review this. I have to admit, I was a bit confused (and remain a bit confused) about that the intention is here. I don't really understand what eventTime represents, nor what this gains us?

[deveshbervar]

Hi @EdwardMoyse,

Thanks a lot for the review!

What eventTime is

eventTime (in nanoseconds) is optional event-level timing information from real or simulated data. It represents the total time span of the physics event (e.g. drift time, readout window, or time-of-flight).

This comes from the original request in #406 and the HallD event viewer experience: real timing (instead of purely visual animations) helps physicists quickly spot reconstruction bugs like wrong hit ordering or timing issues.

What this PR adds (minimal & non-breaking)

• Optional EventTime support in the EDM (EventDataLoader + getEventTime?())
• PhoenixLoader extracts eventData.time (if present) and forwards it to AnimationsManager
• AnimationsManager gets:
  • setEventTime(timeNs)
  • getTimeProgress() → returns normalized progress [0, 1]
  • update(deltaSeconds) → advances internal time

Nothing changes for existing events or animations — this only introduces a small foundation for future time-driven (realistic) animations.

Next steps

I'm happy to simplify further:

• Remove the dat-gui slider (added only for testing), or
• Reduce this PR to EDM only and move the animation helpers to a follow-up.

What direction would you prefer?