fix: reject blocking/state-releasing Lua ops inside callbacks (#3)

[srgg]

Summary

Fixes the SIGSEGV (and related engine-freeze) when a synchronous blocking Lua
operation is called from inside a subscription/PTY callback.

Two hazard classes on the single, stateMutex-guarded lua_State:

• State-releasing (the crash vector): blim.sleep and io.read — and
  transitively blim.term.read_char(wait_ms) via its polling loop — release the
  mutex mid-L.Call, letting another DoWithState reenter the in-flight state
  from another goroutine and corrupt it → SIGSEGV in lua_getinfo.
• Blocking-while-holding-state: characteristic.read()/write() and
  blim.subscribe do a synchronous BLE round-trip while holding the mutex,
  freezing the main loop and every other callback and risking a deadlock with
  the BLE event path.

Change

• Single chokepoint guard LuaEngine.raiseIfInCallback(L, op): while a callback
  holds the state (inCallbackCount > 0) these five ops raise a clean,
  recoverable Lua error instead of proceeding. Self-cancel via the callback's
  cancel() argument stays allowed.
• inCallbackCount moved to LuaEngine (owner of the state and mutex) so
  LuaEngine-registered io.read can consult it without an upward dependency
  on LuaAPI; its increment/decrement is made panic-safe (deferred) so a
  StackTrace-crash panic in L.Call can no longer leak the counter.

Tests

• Deterministic regression tests for all five guarded ops, grouped under
  TestCallbackBlockingOpGuards.
• Verified: full internal/lua suite green, -race -count=1 clean, go vet
  and gofmt clean; legitimate main-loop blim.sleep / characteristic.read
  paths unaffected.

Follow-ups (out of scope, documented)

• Safe blocking inside callbacks (coroutine-per-callback scheduler) is captured
  as deferred work in RFC-001-lua-callback-coroutine-scheduler.md.
• Panic-safety of the counter is a defensive fix; a direct regression test needs
  a fault-injection seam (not deterministically reproducible in the harness).

Fixes #3