Add automatic datatime column as needed when running raiderCombine.py

[jlmaurer]

Description

Running raiderDownloadGNSS.py and then raiderCombine.py directly fails because the datetime column may not exist. This PR allows for adding it on-the-fly if needed.

readZTDFile now builds the Datetime column from whichever time information the file actually provides, in this order:

1. a Date column, optionally combined with a times seconds-of-day column,
2. an existing Datetime column,
3. a YYYYMMDDTHHMMSS timestamp parsed from the filename.

When none of those are available it raises an error naming the columns it did find, instead of surfacing a cryptic pandas parsing failure. The filename fallback stamps every row with a single timestamp, which is correct for a single-epoch delay file and lossy for anything covering several epochs, so it logs a warning saying so.

Two further behavior changes worth reviewing deliberately

These go beyond the datetime column and are easy to miss in the diff:

• Coordinate backfill. Lat/Lon/Hgt_m are copied into the GNSS frame from the RAiDER delay file, keyed on station ID, for GNSS ZTD files that carry no station coordinates (e.g. UNR per-station delay files). IDs absent from the RAiDER file get NaNs and are dropped downstream, since they could not have been matched anyway.
• Hard failure on zero overlap. The workflow now raises when the RAiDER and GNSS files share no common observations. Previously the empty frames propagated into the per-station variance analysis and surfaced much later as a KeyError on a column that was never created (e.g. sigma_model_neg). This turns a previously-completing — though meaningless — run into an explicit abort, so it is a behavior change for anyone whose inputs do not overlap.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have added an explanation of what your changes do and why you'd like us to include them.
• I have written new tests for your core changes, as applicable.
• I have successfully ran tests with your changes locally.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[jlmaurer]

@sssangha this one is also ready; note that this is built on top of #808, so that one should be merged first.