blackboard_write: make status-open check atomic with the response insert

audit-general-ca finding, MED, verified against live hub.mjs:9041-9069: /blackboard_write does stmtBbGetEntry.get() then checks status==='open', then later an unconditional stmtBbInsertResponse.run() - a check-then-act gap, not an atomic guard. Cannot interleave in the CURRENT single Node process (confirmed, matches this epic's established single-process reasoning), but nothing in the code enforces that invariant, so a future multi-process/multi-hub deployment (WAL-mode sqlite supports concurrent writers) could admit a response after cancel deletes/closes the entry. Fix per audit: make response admission one atomic INSERT...SELECT...WHERE EXISTS(entry_id, status='open'), 0 rows -> reread and return bb_entry_closed. Same idiom already used for bbCancelTxn and the notify_state claims - apply it here for consistency, not urgency.