Localization parity guard is path-filtered to clients/** — server-only key additions ship a latent gap and red the next innocent PR #964

Summary

The client-side localization/parity guard is path-filtered to clients/**, so a PR that adds localization keys only on the server passes CI with no client copies — and main stays green while the gap sits latent. It surfaces only later, when some unrelated PR happens to touch clients/** and inherits a failure it did not cause.

Observed

While rebasing PR #959 onto current main, the merge surfaced 12 plugins.discovery.* keys present server-side with no client counterparts. The PR that introduced them was green, and main was green. The keys had been sitting unmatched because no PR since had touched the client tree.

Why it matters beyond the inconvenience

Two costs, and the second is the expensive one:

1. The gap ships. Until someone touches clients/**, nothing tells us the client is missing strings — so a released client can render untranslated or missing text for keys the server already emits.
2. The failure lands on the wrong PR. The next author to touch the client tree gets a red CI naming strings they never wrote. That is exactly the pattern that costs a day: the failure is real, the diff is innocent, and the natural response ("what did I break?") is a dead end. This repo has burned CI cycles on precisely that shape before (a stale branch inheriting main's state).

Suggested direction (not prescriptive)

Make the check run whenever the server catalogue changes too — i.e. trigger on src/MeshWeaver.Messaging.Hub/Localization/** in addition to clients/**, so the PR that adds a key is the PR that has to add its client copy. That keeps the cost with the author who created it, which is the property that makes a guard useful rather than a tax on bystanders.

Worth checking at the same time whether the other client-parity ratchets have the same blind spot — there are at least three scrapers of BlazorViewRegistry.cs (including clients/react-native/src/parity.test.ts), and if they are all path-filtered the same way, they share the failure mode.

Provenance

Found while resyncing #959; that PR resynced the specific keys, so this issue is about the guard gap, not those 12 keys.