fix(bloom): carry #n through union and bound create n to uint32

[akshay-xp]

What

Fixes two #n-handling gaps in BloomFilter found in a post-review sweep (Closes #107), siblings of the blocked union fix (#106).

• union rebuilt its result from new BloomFilter({ m, k, seed }), whose constructor re-derives #n from m/k. It never restored the operand's stored #n, so the union reported a different bitsPerKey/rate and a.equals(a.union(empty)) was false. Membership was never affected (m/k/seed exact) - no false negatives.
• create set #n = n without assertUint32, unlike blocked's create, so a large n (e.g. 6e9) truncated silently into the uint32 frame field.

How

• Extract #withN(params, n) that constructs and assigns #n; route create, fromBytes, and union through it so the carry-#n invariant lives in one place.
• Add assertUint32(n, "n") in create where the unbounded n enters.
• Regression: union now asserts it preserves the operand bitsPerKey and equals the receiver; create rejects n > 2^32-1 and still accepts 2^32-1.

Patch changeset included; folds into the pending 0.6.0 release.

Verification

• pnpm --filter distillate test: 166 passed
• typecheck, lint, format:check, api:check: all green (no public API change; #withN is private)

🤖 Generated with Claude Code