Fixes the data race in #1365 between PollFetches (takeBuffered -> finishUsingAllWithSet -> cursor.setOffset) and handleListOrEpochResults' cursor.setOffset.

Root cause

A group whose members carry both cooperative and eager balancers (the standard migration config, e.g. Balancers(CooperativeStickyBalancer(), RangeBalancer())) runs cooperatively until a member supporting only an eager protocol joins; the group's protocol vote is then forced to eager. The client followed the flip with only a warning:

1. The prior cooperative session revoked nothing at its end (correct for cooperative).
2. handleJoinResp flipped g.cooperative to false.
3. diffAssigned short-circuits for eager consumers and returned the entire assignment as newly added, and prerevoke (gated on cooperative) invalidated nothing.
4. fetchOffsets -> assignPartitions(assignWithoutInvalidating) issued list/epoch loads (and direct offset sets) for partitions whose cursors were still fetching: two owners per cursor, and the load's completion raced concurrent polls' cursor updates.

The Java client pins each member's rebalance protocol at construction from its own assignor list (a mixed-list Java member revokes everything on every rejoin, forever), so a live member there can never flip. franz-go follows the group-selected protocol per generation - cooperative rebalancing whenever the whole group supports it - so it uniquely owns this transition.

Fix

On a downgrade join, enter the eager era the way an eager session would have left the prior one, before offsets are fetched: invalidate all assignments, call onRevoked with the prior assignment (so final work can commit), and clear commit state. The old "not supported per KIP-429" warning was wrong per the KIP's downgrade section and is replaced with an INFO describing the revoke.

A final autocommit between the downgrade sync and the revoke can land after another member fetched offsets; that window yields duplicates only (at-least-once holds) and cannot be closed client-side, since the selected protocol is only learned from the join response.

Verification

• New kfake regression test (TestIssue1365CooperativeDowngrade): one member advertises [cooperative-sticky, sticky] and consumes hot while a second joins with only [sticky]. Pre-fix it reproduced the exact reported race pair in 3 of 5 -race runs; post-fix, 27/27 clean, and every partition resumes consuming after the downgrade revoke.
• kfake suite -race -skip ETL: pass, zero races.
• 85 varied -race runs of pure cooperative-sticky churn confirm the invariant holds without a downgrade (the flip is the only feeder found; two independent full traces of the load/fetch ownership machinery agreed).

#1271 and the "partition fetched while offsets concurrently fetched" oddity in #1222 share this signature and were both mixed-config-capable groups; this plausibly retires those as well.

Closes #1365