bees: gate dedupe on the src's resulting reference count

bees: gate dedupe on the src's resulting reference count

The scan_next candidate gates rejected a dedupe only when an extent was
*already* at rewrite.refs-max references (a binary "src already full" test).
A single dedupe redirects every reference of the dst onto the src, so a src
sitting just under the limit could still absorb a many-ref dst and overshoot
the ceiling by thousands — the reference-cluster blow-up seen in extent-scan
stress runs, where hot canonical extents climbed well past the configured
limit.

Add scan_next_refs_would_exceed(src_refs, dst_refs, refs_max): the src ends up
with the sum of the two counts, so reject when that sum exceeds the ceiling
(landing exactly on it is allowed).  Both process_candidate sites use it —
Plan A (candidate is the src, m_start the dst) and Plan B (roles swapped, same
symmetric sum).  The Planner-level "reject truncated dst ref list" check stays
binary: it fires before any src candidate exists to sum against.

The additive form also subsumes the old truncation guard: real extents have at
least one reference, so if either side is already at the ceiling the sum
strictly exceeds it.

test_refs_ceiling_gate pins the boundary (> not >=) and the summation,
including the src-under-limit / dst-many-refs overshoot the binary gate let
through.

Assisted-by: Claude-Code:claude-opus-4-8