Serialise a connection across the whole primitive; finalize on every path

A SQLite connection is a SERIAL resource and this library treated it as a shared one. SQLite ends a connection's implicit read transaction only when NO statement on it is active, so if fiber A has a statement open and fiber B runs a query on the SAME connection, B's read transaction cannot be released when B finalizes -- A is still using the btree. The connection is pinned to B's snapshot until A completes, and every later read on it silently misses anything committed in between.

Measured against kiln, whose controller shares one connection between its HTTP app and its run loop: /api/groups answered HTTP 200 with a pre-commit view of its own database -- 55 rows where an independent connection to the same file saw 755 -- and stayed that way until the process restarted.

Three defects, three changes.

1. THE CONNECTION IS NOW HELD ACROSS THE WHOLE PRIMITIVE. sqlite-query, sqlite-query-row, sqlite-run and sqlite-exec take a per-connection lock for their whole duration, yields included.

   Guarding only the busy window would not have been enough, and that is a
   measurement rather than a judgement: a fiber yields inside an UNCONTENDED
   query too, allocation-driven, roughly once per 450 rows. A witness fiber
   counts ~44 yields across a 20000-row query with no contention anywhere.

   Scope is deliberately the PRIMITIVE. Held any coarser it would deadlock the
   moment a consumer's database helper called another one. At primitive scope
   reentrancy is impossible by construction: no user code runs between prepare
   and finalize -- the call set there is natives plus pure list operations, with
   no callback.

2. STATEMENTS ARE FINALIZED ON EVERY EXIT PATH. sqlite-query finalized only on its else branch and sqlite-run only after a successful step, so a raise from sqlite-step -- the ordinary outcome when the busy budget is exhausted -- leaked the statement. A leaked statement holds the read transaction open for the life of the process, which is what turned a transient stale read into a permanent one. dynamic-wind's after thunk runs when the body raises, verified on this runtime rather than assumed.

3. PRAGMA busy_timeout=N IS HONOURED INSTEAD OF SWALLOWED. It cannot be passed to SQLite: a blocking step freezes the whole cooperative scheduler, measured at 0 witness ticks in two seconds against 4701 for the retrying path. It was accepted and silently ignored -- dead configuration that read as live. It now sets the cooperative retry budget, which is the same intent expressed where this library can act on it. sqlite-busy-budget and sqlite-set-busy-budget! are the explicit form.

BEHAVIOUR CHANGE, stated plainly: concurrent database calls on ONE connection now serialise, and a fiber waiting on a connection whose holder is parked on a contended write waits for that whole busy budget. Callers wanting concurrent database work want separate connections. A wait longer than three times the busy budget raises rather than hanging, so two fibers deadlocking over two connections is a loud error rather than a silent stop.

NOT COVERED, and documented as such: the low-level prepare/step/finalize API cannot be serialised, because the library cannot know when the caller's statement is done; and BEGIN..COMMIT spans several primitives, so another fiber's query can still interleave inside a transaction. Give a transaction its own connection. docs/concurrency.md carries both.

test/test-sqlite-connection-pin.sgl is the regression test: four arms, the first two differing by exactly one read, which is the variable that decides the bug.

Adds sigil-test / sigil-test-runner as dev-dependencies. README has always claimed sigil test --report works and it could not: sigil test refuses to build a native package without them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NuSfnnNgQ81hjRygkkqWM6