v0.4.27: don't join decoder worker on close — fix place-then-delete freeze

stopWorker() ran a 2 s bounded join on the client tick thread. When a
user runs /videoPlace and immediately /videoDelete, the decoder worker
is still inside native grabber.start() doing the initial HTTP probe
(probesize=8 MB, analyzeduration=2 s); that call doesn't honor the
running flag and Thread.interrupt() doesn't unblock native I/O, so the
join blocked the tick thread for as long as start() took — exactly the
brief in-game freeze the user reported.

Signal stop (running=false, audio line stop+flush, worker.interrupt())
and return. The worker is a daemon, the audio tail is already silenced,
the Entry has been removed from the map, and the worker's finally still
closes the grabber whenever start()/grab() eventually returns — nothing
observable depends on the grabber being closed synchronously before
close() returns.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

gradle.properties

@@ -5,7 +5,7 @@ org.gradle.configuration-cache=false
 
 # Mod
 mod_id=video_player
-mod_version=0.4.26
+mod_version=0.4.27
 maven_group=com.ejclaw.videoplayer
 archives_base_name=video_player
 

src/main/java/com/ejclaw/videoplayer/client/playback/JavaCvBackend.java

@@ -180,27 +180,24 @@ public class JavaCvBackend implements VideoBackend {
         // stale srcAddr — closing the grabber there frees the av_frame plane and the next
         // memcpy crashes inside StubRoutines::jbyte_disjoint_arraycopy (exactly the 4K-delete
         // crash dump we saw). So the safe rule is: only the decoder thread touches the
-        // grabber. External stop signals `running=false`, stops the audio line, interrupts the
-        // worker, and joins briefly; the worker's own `finally` calls grabber.close(). Inside
-        // the loop, grab() unblocks via the rw_timeout/timeout options (3 s, set in runLoop)
-        // even on a stuck HTTP read, so the join below normally returns within a frame.
+        // grabber. External stop signals `running=false`, stops the audio line, interrupts
+        // the worker, and returns immediately; the worker's own `finally` calls
+        // grabber.close() whenever grab()/start() eventually returns.
+        //
+        // We deliberately do NOT join the worker. close() runs on the client tick thread (via
+        // VideoPlayback.tick → Entry.close), and the worker can spend several seconds inside
+        // the native FFmpeg probe at the top of runLoop — probesize=8 MB and
+        // analyzeduration=2 s do not honor the `running` flag and Thread.interrupt() doesn't
+        // unblock native I/O. A bounded join() there (the old 2 s) is exactly the "place then
+        // immediately delete freezes the game for a moment" symptom: the worker hasn't
+        // entered the grab() loop yet, so flipping running=false has no effect on it until
+        // start() returns. The worker is a daemon, the audio line is already silenced above,
+        // and Entry has been removed from the active map by the caller — nothing observable
+        // depends on the grabber having been closed before this method returns.
         Thread t = worker;
         worker = null;
         if (t != null) {
             t.interrupt();
-            try {
-                t.join(2000);
-            } catch (InterruptedException ie) {
-                Thread.currentThread().interrupt();
-            }
-            if (t.isAlive()) {
-                // Worker still blocked in native grab() — let it finish on its own. Its
-                // finally still closes the grabber when grab() eventually returns / throws.
-                // No native pointers leak in the meantime because we don't touch them here.
-                VideoPlayerMod.LOG.warn(
-                    "[{}] decoder did not exit within 2 s of stop; orphaning until next grab() returns",
-                    VideoPlayerMod.MOD_ID);
-            }
         }
         ready = false;
     }