JITSU-214 refactor(bulker): centralize batch consumer lifecycle

[absorbb]

Summary

• replace overlapping heartbeat, pointer-swap, and restart coordination with one group-aware runtime shared by batch and retry consumers
• serialize all Kafka consumer operations in one owner goroutine and model assignment changes with epochs
• treat empty assignments as healthy shared-group members and use dynamic membership to avoid static-member fencing
• keep paused members polling, retry failed pause application, and recreate unusable sessions inside the owner loop
• prevent stale buffered records from surviving seeks and reject commits from obsolete assignment epochs

Safety details

• a synchronous rebalance callback applies eager or cooperative assignment changes inside Poll; recreation happens only after the callback unwinds
• records observed during assignment waits or epoch transitions are retained for the valid epoch
• partition-scoped Kafka errors follow the same metrics and recreation policy as consumer errors
• batch destination completion can replay after a rebalance, but cannot commit through a replacement group generation

Stack

This is an architectural follow-up to #1494, which remains the immediate containment fix for JITSU-214. The PR is based on that branch so this review contains only the runtime refactor.

Test plan

• go test -race ./bulkerapp/app -run Test(ConsumerRuntime|ConsumerMaintenance|MembershipLossReason) -count=1
• go test ./bulkerapp/... -run ^$ -count=1
• go vet ./bulkerapp/...
• go test ./bulkerapp/app -run ^(TestGoodAndBadStreams|TestBatchSizeBytes|TestEventsRetry)$ -count=1 -timeout=15m

[jitsu-code-review]

Reviewed the batch/retry consumer lifecycle refactor, including rebalance callbacks, assignment epochs, pause/suspend polling, and transactional offset paths.

No actionable findings.