fix(abr): guard abandon-rules check after destroy

[AmPlace]

Summary

• return early when an ABR abandon-rules check reaches a controller whose HLS reference has been released
• add a regression test that invokes the retained callback after hls.destroy()

Observed behavior

The following exception was observed in Chrome 149 Stable on macOS while rapidly switching live HLS sources:

Uncaught TypeError: Cannot read properties of null (reading 'autoLevelEnabled')
    at AbrController._abandonRulesCheck (abr-controller.ts:244)

Original application-side workaround:
AmPlace/waveflow@e4fdbde

The exact browser scheduling or re-entrant path that causes the post-destroy invocation has not been isolated.

Confirmed failure path

AbrController.destroy() releases references by setting this.hls to null. _abandonRulesCheck currently dereferences hls.autoLevelEnabled without checking whether the controller has already been destroyed.

The callback now returns when the controller no longer has an HLS instance. Active ABR behavior is unchanged. The regression test covers safe behavior after destroy; it does not claim to reproduce the macOS browser timing.

Fixes #7937

Checks

• npm run type-check
• npx eslint src/controller/abr-controller.ts tests/unit/controller/abr-controller.ts
• npx prettier --check src/controller/abr-controller.ts tests/unit/controller/abr-controller.ts
• Rollup builds, TypeScript declaration build, and API Extractor
• npx es-check
• built-bundle smoke check invoking a retained _abandonRulesCheck callback after hls.destroy()

[AmPlace]

Thanks for landing the fix in #7939. Since this PR proposed the same
post-destroy guard and included a regression test before #7939 was opened,
could you reference #7938 from #7939 so the contribution history is preserved?

Would you also consider merging the regression test as a small follow-up,
or let me know how you’d prefer this PR to be handled?