Action Queue Protection and Recovery

[Guffawaffle]

When another player destroys a queued hostile, native target removal can leave the next target idle. This combines two guarded recovery paths so the queue can continue through the game's existing planner:

• Thin Queue Protection resumes after the native planner or watchdog removes a stale prefix and leaves the exact remaining queue idle. It also processes a confirmed destroyed target left at the queue head. Enabled by default.
• Faster Queue Recovery advances after a matching failed course response arrives for a target already removed from the queue. Opt-in, as before.

[control]
thin_queue_protection = true
faster_queue_recovery = true

Both respect queue_enabled. The previous advanced.queue.thin_queue_protection setting remains a fallback when the new control key is absent. Recovery rechecks queue identity and state, retains native eligibility checks, and does not force engagement flags or retry counts. There is no new polling loop. The obsolete combat-completion repair remains retired.

Hooks are limited to compatible Windows x64 clients; other platforms retain native behavior. The three restored hook sites were checked against the installed client 262 metadata and native function extents.

Validation: Windows release build, both queue-policy suites (including 44 restored protection assertions), all 11 example TOMLs, and diff checks passed. The same recovery code passed live Windows wave testing in the combined downstream build, with both features initialized; the standalone upstream artifact has not been runtime-tested.

The guarded existing class lookup is already in dev through merged #292. Queue storage/layout and planner/watchdog validation remain feature-specific.

[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.