ElementSet doesn't record whether it came from TLE or OMM, so Δ_data can't use the right quantization step #27

Plan reference

docs/spec.md §4.1:

So Δ_data depends on which representation was ingested, and an application mixing the two is comparing element sets of different precision. Osculator reads OMM wherever both are available, and records which format each element set came from.

What exists today

• Osculator.Core/Elements/ElementSet.cs has no source or format field.
• TleParser and OmmJson both produce a plain ElementSet.
• DataTerm and ElementFieldQuantization (Osculator.Core/Residuals/) work out each field's quantization step themselves.

What's missing

Once an ElementSet exists, nothing says whether its fields were quantized to TLE precision or to OMM precision. The spec's own example: B* has a five-digit mantissa in a TLE and roughly eight digits in OMM JSON. Without the format, Δ_data on an OMM-sourced set has to assume TLE steps, or the reverse, and M2's TLE-vs-later-element comparison can't tell when it is comparing sets of different precision.

Acceptance criteria

• ElementSet carries an ElementSetFormat (Tle, Omm).
• TleParser sets it to Tle and OmmJson sets it to Omm.
• Tests on the committed ISS TLE/OMM pair assert the format on both paths.
• DataTerm/ElementFieldQuantization pick each field's step from the recorded format, with a test showing that B*'s step differs between the two.

Dependencies

None. This also relates to open #23 (the epoch field in DataTerm.Measure) but is independent of it.