fix(Niger): the merge_how comment claims an effect it does not have

[ligon]

Found by the adversarial re-verification of #643, which measured the claim false and correctly noted it is pre-existing on development (landed by 3488b791), not introduced by that PR — so it is fixed here rather than blocking it, and it would otherwise ship in the next release.

The claim

# `left` is load-bearing: the offsets file has ONE trailing row with a
# null grappe (and null coordinates).  Under the default `outer` that row
# arrives as a phantom cluster with a null v; `left` drops it...
merge_how: left

Measured

Built with and without merge_how: left: the table is md5-identical (1,599 rows; 2011-12 at 270 clusters, 0 null v). Under outer the null row does not survive — the (t, v) groupby drops it.

left is kept. It states the intent (df_main is authoritative for which clusters exist) and would matter if downstream null-key handling changed. Only the justification is corrected, and the comment now says defensive rather than load-bearing.

Why it is worth a PR

Same defect class the #323 sweep has been finding all day — a confident, specific, false statement in a tracked file. It is worse here than in documentation: data_info.yml is the file the next editor of this wiring actually opens, and the corrected version already existed in Niger/_/CONTENTS.org and the ledger. The true and false versions were coexisting in one country tree, with the false one in the config.

Comment-only; Country("Niger").data_scheme parses unchanged (23 tables).

Refs #643, #627, #323.