[tobias-tengler]

Creating a Kafka event with a composite cursor groups the same partition frontier by topic once to calculate the cursor size and again to format the cursor.

This PR reuses the groups created during sizing when formatting that event. Standalone formatting, cached single-partition and no-cursor paths, cursor bytes, rollback and delivery behavior remain unchanged.

All 41 focused tests pass on .NET 10 and 11 with Release/style checks.

Against pinned main 15888585e14566bc1fd3e6ef50cac5ff34f47785, the complete CreateMessage factory with full body/cursor consumption and owner disposal improves three-partition CPU-bound elapsed by 13.53%; two topics improve 9.70%, below the gate. Cached and no-cursor controls cost +1.77 ns (1.82%) and +0.55 ns (1.86%). The table uses arithmetic means of two launches per version. All allocation rows are unreliable, with no allocation claim: native pairs main → PR are cached 64/0 → 64/64 B, two topics 0/560 → 344/344 B, no cursor 0/64 → 64/0 B, and three partitions 592/592 → 376/317 B; adverse arithmetic means remain visible. Scope is event construction, consumption and disposal.

Method	Version	Mean	Ratio	Allocated	Alloc Ratio
Kafka cached single-partition control	main	96.963 ns	1.00	32 B	1.00
Kafka cached single-partition control	PR	98.731 ns	1.02	64 B	2.00
Kafka event, two topics	main	226.801 ns	1.00	280 B	1.00
Kafka event, two topics	PR	204.793 ns	0.90	344 B	1.23
Kafka no-cursor control	main	29.574 ns	1.00	32 B	1.00
Kafka no-cursor control	PR	30.124 ns	1.02	32 B	1.00
Kafka event, three partitions	main	247.878 ns	1.00	592 B	1.00
Kafka event, three partitions	PR	214.329 ns	0.86	346.5 B	0.59

[github-actions]

Patch coverage

100.0% of changed lines covered (7/7)

File	Covered	Changed	Patch %
…/Fusion.Subscriptions.Kafka/KafkaCompositeCursorFormatter.cs	5	5	100.0% 🟢
…/src/Fusion.Subscriptions.Kafka/KafkaEventStreamBroker.cs	2	2	100.0% 🟢

---

Project coverage: 59.0% (311450/527761 lines)