chore: require a strict majority to pass a gitvote vote

[gbartolini]

What

Raises this repository's gitvote thresholds from 50 / 66 to 50.01 / 66.66.

Why

gitvote decides a vote with in_favor_percentage >= pass_threshold (src/results.rs), where the denominator is the whole electorate rather than the votes cast.

The >= is the problem. At a flat 50, an even-sized electorate splitting exactly down the middle clears the bar, so a 2-2 tie on a four-owner repository passed the motion. A simple majority is strictly more than half, and a percentage cannot express "half plus one vote", so the bar has to sit just above 50 instead.

Electorate	In favor	%	>= 50	Correct?
7	4	57.1	pass	yes
7	3	42.9	fail	yes
10	5	50.0	pass	no, that is a 5-5 tie
10	6	60.0	pass	yes

Odd-sized electorates were never affected: the percentage cannot land on exactly 50, so >= 50 and > 50 agree.

Why 50.01 — the smallest possible majority of N voters is 50 + 100/N percent, which stays above 50.01 for any N up to 10000. It rejects an exact tie and accepts every real majority.

Why 66.66 and not 66.67 — two-thirds is 66.666…, so a flat 66 sat fractionally under its own bar (33 of 50 is 66.0 and would have passed). Rounding up to 66.67 would overshoot: for an electorate divisible by three the exact two-thirds computes to 66.6666…, which falls under 66.67 and would break a legitimate 2-of-3. 66.66 sits in the gap.

pass_threshold is an f64 in gitvote's config (src/cfg_repo.rs) with no integer constraint, so fractional values parse fine.

Scope

This file is generated from cnpg-infra's gitvote-policy.yaml via scripts/render-gitvote-config.sh. The change was made there first and regenerated here, so a later sync will not revert it. The same two values are being applied across every repository in the organisation in one pass, including governance's hand-maintained copy.