Release 0.42.0

[tudddorrr]

No description provided.

[claude]

PR Review: Release 0.42.0

---

🟡 Code Quality / Potential Bug

pending_events_flushed can emit twice in a single flush cycle

In events_api.gd, flush() has a retry path for the case where a second flush was attempted during an active flush (_flush_attempted_during_lock). When the retry flush also has events to process, the signal is emitted once by the recursive call and then again by the outer call:

if _flush_attempted_during_lock:
    _flush_attempted_during_lock = false
    await flush()        # emits pending_events_flushed if _queue has events

pending_events_flushed.emit()  # always emits, even after recursive call already did

For the _handle_quit use case this is harmless — await events.pending_events_flushed resumes on the first emission. But pending_events_flushed is now a public signal (documented with ##), so external listeners will receive two notifications per flush cycle whenever a retry flush has queued events. This is a realistic scenario: tracking 10+ events rapidly during an ongoing flush triggers _flush_attempted_during_lock, and if more events were queued, the recursive flush will complete and emit first.

Suggested fix — only emit from the outermost invocation:

if _flush_attempted_during_lock:
    _flush_attempted_during_lock = false
    if _queue.size() > 0:
        await flush()
        return  # recursive call emitted the signal
    # queue is now empty; fall through to emit below

pending_events_flushed.emit()

---

🔵 Minor

Unnecessary intermediate variable in get_cached_entries

var entries := _entries_manager.get_entries(internal_name).filter(...)
return entries

The deprecated get_cached_entries_for_current_player returns the filter() result directly. The new method is inconsistent in introducing a redundant intermediate variable.

---

No issues found

• Backwards compatibility: get_cached_entries new options parameter has a default value, existing callers unaffected.
• CI upgrade to Godot 4.6.1 with the .godot regeneration step looks correct.
• _handle_quit coroutine pattern is sound given auto_accept_quit is disabled — the process stays alive until get_tree().quit() is explicitly called.