Correct two stale headwater neighbour columns in AS and NA exports #231

Yushan's validation identified two headwaters with their downstream neighbour stored in rch_id_up_1 and zero in rch_id_dn_1:

• AS: 45220300256 → 45220300245
• NA: 71382000696 → 71382000683

The normalized reach_topology rows, main neighbours, counts, reciprocal references and dist_out already agree on the correct direction. The NetCDF neighbour arrays are also correct. The stale scalar columns are present in the working DuckDB, GeoPackages and reach Parquet exports.

The local correction moves those two IDs to rch_id_dn_1 and clears rch_id_up_1, using a bounded SWORDWorkflow.repair_headwater_neighbor_columns operation with value snapshots. It verifies the existing direction evidence and commits both repairs together. It avoids unrelated schema migrations and recalculation.

Validation:

• Three targeted tests passed: preserve graph/areas and support idempotent reruns; roll back both repairs and audit records if either connection disagrees; refuse the v17b reference.
• Full working-database comparison against the backup confirms exactly four changed reach cells; all other reach fields and normalized topology rows are identical. Node drainage-value fingerprints are unchanged.
• Corrected local AS/NA GeoPackages and reach Parquets were prepared and verified. NetCDF required no correction.
• Original shipped export files and all three frozen drainage-area candidates remain unchanged. Nothing has been published or released.

Implementation and data changes are local and uncommitted. This issue tracks the correction and any subsequent release packaging.