Action Queue Protection and Recovery

[Guffawaffle]

When another player removes a queued hostile, native target removal can leave the next target idle. This combines two guarded recovery paths through the game's existing planner: default-on Thin Queue Protection after exact native prefix removal/destroyed-head handling, and opt-in Faster Queue Recovery after a matching failed course response for an already removed target.

Following #313, default-enabled [patches].actionqueuerecoveryhooks and thinqueueprotectionhooks independently control installation. Installed callbacks check current [control].faster_queue_recovery, thin_queue_protection and queue_enabled values. Disabled observations and both Toggle Queue transitions invalidate pending recovery records; session cleanup releases weak handles. Full-family readiness, complete method/field/value-type ABI and distinct targets retain native behavior on incompatible or partial installations. Thin protection calls the existing engage owner. There is no new polling loop. The earlier advanced.queue.thin_queue_protection fallback retains explicit opt-outs; the obsolete completion repair remains retired.

This existing recovery implementation supports compatible Windows x64 clients; other platforms retain native behavior. It contains no settings or notification stack.

Validation: Windows release build at ff75bb5, both existing queue suites and all 11 example TOMLs pass. Final correction removes only an unused installation helper and its obsolete assertions; both suites were rerun. Three independent reviews cover the complete PR and correction. All seven Windows270 native overwrite windows fit measured extents. Earlier downstream wave smoke covers its earlier combined artifact; exact-candidate waves, adapter-level toggles and partial-install execution remain unqualified. Delayed same-target responses lack a server request ID and remain a documented limitation. CI starts on publication without waiting for results.

[Guffawaffle]

This isn't working as well as my previous implementation on my personal branch. Moving back to draft until I figure it out.

[Guffawaffle]

This is now gloriously effective for me in group waves.

[Guffawaffle]

Hook/feature alignment follow-up for #313

Follow-up to #313: keep hook installation independent of feature enablement, with default-enabled compatibility switches under [patches] and feature checks inside the installed hooks.

InstallActionQueueRecovery() and InstallThinQueueProtection() return early based on [control].faster_queue_recovery and thin_queue_protection, and are called outside the patch registry. Register them with independent default-enabled [patches] switches, remove feature-based installer returns, and retain the existing runtime Enabled() checks (including queue_enabled). Preserve the Windows/metadata/layout compatibility checks and native planner behavior. This is a standalone correction.

Published c60b6f8: independent default-enabled queue hook switches, current runtime eligibility, disabled/toggle pending-request invalidation and full-family guards. Removed the unused feature-derived installation helper/assertions. Windows build at ff75bb5 passed; both policy suites reran after the final deletion-only delta, all 11 TOMLs passed, and three independent lanes reviewed full PR plus correction. Seven Windows270 static fits pass. Exact-artifact wave/toggle/partial-install execution remains unqualified; delayed same-target responses retain the documented request-ID limitation. New CI is queued; moving on without waiting.