Reconcile type field with lakeflag for HarP/lake-sandwich corrections

[jameshgrn]

Summary

v17c introduced ~5,770 reaches with lakeflag=1 but type=1 (river) — a combination that was rare in v17b (88 reaches pre-existing).

Root cause: HarP and lake sandwich corrections updated lakeflag 0→1 but did not update type 1→3 (lake_on_river). This was intentional: type is encoded as the last digit of reach_id, so changing it changes reach_ids — a breaking change we deferred.

Affected reaches

Source	lakeflag=1, type=1 introduced
HarP corrections	~5,507
Lake sandwich corrections	~270
Total	~5,770

v17b baseline had 88 such reaches (pre-existing, not introduced by us).

Impact

Any downstream user (e.g. LakeFlow) filtering on both lakeflag and type at river-lake boundaries will see these as river reaches (type=1) despite being reclassified as lake water (lakeflag=1).

Resolution needed

1. Establish a policy for reach_id changes (do we allow last-digit changes across versions?)
2. Reclassify the ~5,770 reaches from type=1 → type=3 and update their reach_ids accordingly
3. Update all topology references (rch_id_up, rch_id_dn, rch_id_up_main, rch_id_dn_main) to reflect new reach_ids
4. Notify downstream users (LakeFlow, etc.) of any reach_id changes

Notes

• edit_flag column tags affected reaches (harp_lake, lake_sandwich) — can be used to identify them
• Flagged by LakeFlow team (Hana) during v17c review

[jameshgrn]

Deferring to v18. Changing type changes the last digit of reach_id — a breaking change for all downstream users (LakeFlow, etc.). The 5,770 reaches with lakeflag=1, type=1 are tagged via edit_flag (harp_lake, lake_sandwich) so downstream users can filter them. We'll address the type/reach_id reconciliation as part of the v18 schema revision.