Why is `@EmbeddedKafka` valuable for testing a Kafka consumer's rebalancing or retry behavior specifically?

Those behaviors only emerge from real broker interactions (partition assignment protocol, actual redelivery on uncommitted offsets) that a mock can't simulate. `@EmbeddedKafka` spins up a real (in-process) broker for the test, so you can genuinely trigger a rebalance or force a redelivery and assert the consumer handles it correctly, not just that its code compiles.