Recover and qualify interrupted topic deletion on the 3.9 bridge

[bringhurst]

Problem

An interrupted 3.0 topic deletion can remove the partition's leader/ISR znode but leave reassignment fields in the topic parent. A returning 3.9 controller then repeatedly fails reassignment startup. In the retained failed recovery run, producer-ID allocation also timed out.

Change

Under the existing cleanup gate, and only while deletion is enabled, recover marked deletions that have no leader/ISR state. Preserve every assigned replica, fence the ZooKeeper write, and remove only the affected reassignment entries. Leave unmarked topics, partitions with leader state, and disabled paths alone. Normal replica deletion acknowledgements still control removal.

Add a maintained startup prelude for both broker generations. It seeds the interrupted deletion, requires assignment removal, recreates the name, and verifies exact records with the unchanged 3.0 client jar. It runs with bridge mode off, so its log markers cannot stand in for mixed-phase protocol checks.

Scenario revision 6 requires both generations' deletion and record checks. The auditor rejects revision 5 and each missing evidence row. The CI companion now selects #596, which also repairs the direct native response bit expected by #595.

Evidence

• The real-broker reproduction fails before the repair on both generations.
• The maintained native prelude exposed the direct 3.0 response-bit gap. With Recover interrupted topic deletion on the 3.0 bridge #596 it passes on both generations, including exact recreated records.
• KafkaControllerTest and TopicDeletionManagerTest pass: 15 tests on Scala 2.12 and 2.13. Actual RAT passes.
• 84 Python tests pass. Negative evidence fixtures failed before adding the new required rows and scenario revision.
• Partial process bundles remain marked incomplete; they are not full qualification.

The latest #594 CI also has a separate recreated-topic metadata timeout. A diagnostic replay found long old-client bootstrap waits, but this PR does not claim that separate failure is resolved. No client profile, deadline, or record assertion was relaxed. Full final-pair qualification and release approvals remain required.

Based on #594. The 3.0 counterpart stays in its own release history.