pdp3.sh: respect pre-staged broadcast nav on same-day runs

[bobvan]

Summary

PrepareRinexNav in scripts/pdp3.sh has four code paths that supply
the broadcast-ephemeris file brdm{doy}0.{yy}p for a processing
session. Three of them respect an already-present file via
if [ ! -f "$rinex_dir/$rinexnav" ]; then ... (lines 2112, 2122,
2143). The fourth — the same-day hourly download + merge block at
line 2076 — runs unconditionally and clobbers any pre-staged file via
mv -f at line 2095.

This breaks workflows in which the operator pre-stages a multi-GNSS
brdm at the canonical name (e.g., a full BRDM00DLR or
BRDC00IGS file containing GPS + GLONASS + Galileo + BeiDou +
QZSS records) and then runs pdp3 -m S for the current UTC day:
the hourly fetch downloads GPS + GLONASS hourly nav,
merge2brdm.py produces a GPS+GLONASS-only merged file, and the
mv -f overwrites the operator's multi-GNSS brdm. Downstream
processing then rejects Galileo and BeiDou observations as
DEL_BADRANGE because their ephemerides are no longer present in
the (now-overwritten) brdm.

Reproduction

# 1. Pre-stage a multi-GNSS brdm at the canonical name for today's UTC day
year=$(date -u +%Y); doy=$(date -u +%j); yy=${year:2:2}
cp BRDM00DLR_S_${year}${doy}0000_01D_MN.rnx "$RINEX_DIR/brdm${doy}0.${yy}p"

# 2. Run pdp3 against an obs file in $RINEX_DIR
pdp3 -m S -sys GE my_station_${doy}.obs

Result before this patch: pdp3 logs ===> Merging brdm${doy}0.${yy}p ...,
overwrites the pre-staged file with a GPS+GLONASS-only product, then
emits DEL_BADRANGE for every Galileo observation in tedit's
output.

Result after this patch: the existence check short-circuits the
same-day download/merge branch, the operator's pre-staged file is
preserved, and Galileo + BeiDou observations are processed normally.

Fix

Add an existence guard to the same-day branch, matching the pattern
used by the three blocks that follow it. One-line change:

         # Try downloading hourly navigation file when processing current day's data
-        if [ $(date -u +"%Y%j") -eq "$year$doy" ]; then
+        if [ $(date -u +"%Y%j") -eq "$year$doy" ] && [ ! -f "$rinex_dir/$rinexnav" ]; then
             local navgps="hour${doy}0.${year:2:2}n" && rm -f "$navgps"

The new condition matches the symmetric pattern already in use at
lines 2112, 2122, and 2143: each of those blocks is wrapped in
if [ ! -f "$rinex_dir/$rinexnav" ]; then. Block 2076 is the only
nav-acquisition branch in PrepareRinexNav that did not previously
respect a pre-existing file.

Backward compatibility

When no file is pre-staged at $rinex_dir/$rinexnav, the new
condition evaluates the same as the old one and the same-day hourly
download + merge runs as before. This change only affects the case
where the operator has explicitly staged a file at the canonical
name, which is exactly the case where the previous behavior was
silently destructive.

Field-tested context

We hit this in a lab automation pipeline that pre-stages BKG-mirrored
multi-GNSS brdm files for same-day captures (5–60 minute arcs from
ZED-F9T receivers, processed within the same UTC day they were
captured). The local fix has been running across four lab hosts for
~12 hours without regressions; the only behavior change is that
pre-staged Galileo + BeiDou ephemerides are now respected.