Stop POSSIBLY_NSFW_ACCOUNT from requiring 11 matches in a window of 10

[Pitchfork-and-Torch]

Bug

safety-label-user-agg is the only writer of POSSIBLY_NSFW_ACCOUNT. That label is how soft-NSFW posting becomes an account signal (nsfw_author_ads in gizmoduck hydration → ads brand safety).

The production default rule is unsatisfiable:

"windowSize": 10,
"minimumMatchingPosts": 11

matchesPostLabelCount does posts.take(windowSize).filter(match).size >= minimumMatchingPosts. A window of 10 can never contain 11 matches. enabled: true does not matter. The soft-NSFW account path never writes.

NSFW_HIGH_PRECISION (3 of last 5) still works. Accounts that post SOFT_NSFW without hitting 3/5 high-precision posts get no account label.

Validation allows this: maxConfiguredWindowSize = 10 and maxConfiguredMinimumMatchingPosts = 11, with no minimum <= window check.

Proof

take(10).size >= 11 is false for every timeline.

Last 10 posts	Before	After
10× NSFW_HIGH_PRECISION / SOFT_NSFW	no label	POSSIBLY_NSFW_ACCOUNT
9× NSFW + 1 clean	no label	no label
3/5 NSFW_HIGH_PRECISION	NSFW_HIGH_PRECISION	NSFW_HIGH_PRECISION (unchanged)

Stale feature-switch copies of the old 11/10 JSON still fire: required count is clamped to the window. Rejecting 11/10 in validRules would have dropped both default rules (all-or-nothing), including the working 3/5 path.

evaluateForTest on 10 labeled posts with the old default returns []. After clamp / 10-of-10 it returns POSSIBLY_NSFW_ACCOUNT.

Fix

1. Default minimumMatchingPosts is 10 (all of the last 10).
2. requiredMatchingPosts clamps minimumMatchingPosts to windowSize so a leftover 11/10 FS payload cannot keep the rule dead.

One file: safety-label-user-agg/postToUserLabelRules.strato.

Not a home-mixer / VF leftover. Not #165 (user-cred linked edges). Not a fork PR.

Fork PR: none