[adrian-andrzjewski]

Explicit AudioBuffer deletion currently deletes its OpenAL buffer and resets the object but leaves the tracked clone in NativeObjectManager. On later cleanup, the manager can try to delete that native name again and hit the stale-object assertion.

Unregister the AudioBuffer from NativeObjectManager during deletion, and add a proxy-based regression test that verifies explicit deletion followed by manager cleanup calls alDeleteBuffers only once.

Closes #1864

Validation:

• :jme3-core:test --tests com.jme3.audio.openal.ALAudioRendererDisposalTest
• :jme3-core:test
• :jme3-core:check
• The regression failed before the fix and passed afterward.

[jaime-jmebot]

Hi Adrian, thanks for tackling this lifecycle bug and adding a focused regression test. The change addresses the core mismatch cleanly: after the renderer explicitly deletes an AudioBuffer's OpenAL name, it unregisters the corresponding manager entry before resetting the object, so later garbage-collection or shutdown cleanup cannot act on a stale clone.

I also checked the test path: it registers a buffer with the manager, exercises explicit deletion, and then runs manager cleanup while counting alDeleteBuffers calls. That directly captures the reported failure mode without requiring a live OpenAL context, and the proxy fails on unexpected API calls so the test stays narrowly scoped. I didn’t find any correctness concerns in the change. The PR reports the targeted test and broader core validation as passing; no CI checks are currently visible here. Looks good to me—thanks for the fix!