docs(blueprint+gate): drop hstore from Tech Stack; note gate-vs-timeout interaction

Two review-pass nits from the v1.1.0-foundation review:

  - Blueprint §6 Tech Stack table still listed the database as
    "PostgreSQL + hstore" with an hstore-for-KV rationale — directly
    contradicting the §8.1 KV rewrite that explicitly rejected hstore
    in favour of JSONB. Updates the row so the high-level summary
    matches the §8.1 reasoning.
  - LocalExecutorClient::execute now documents the permit-vs-timeout
    interaction: when tokio::time::timeout fires the future drops and
    the permit returns, but the detached spawn_blocking thread keeps
    running until the Rhai script winds down. In-use blocking threads
    can briefly exceed the gate's permit count after a timeout. Calling
    it out so future readers don't read the implementation as buggy.

No behaviour change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

crates/orchestrator-core/src/client.rs

@@ -57,8 +57,14 @@ impl ExecutorClient for LocalExecutorClient {
         timeout: Duration,
     ) -> Result<ExecResponse, ExecError> {
         // Acquire before spending any wall-clock budget. The permit is
-        // held until this future returns; spawn_blocking inherits the
-        // gating via the captured `_permit`.
+        // held by this future; on `tokio::time::timeout` firing, the
+        // future drops and the permit returns to the pool — but the
+        // detached `spawn_blocking` thread keeps running until the
+        // Rhai script finishes (or panics). So in-use blocking threads
+        // can briefly exceed the gate's permit count after a timeout.
+        // That is intentional: a new admission can be served while the
+        // already-doomed script winds down, which is preferable to
+        // wedging the slot for the worst-case timeout duration.
         let _permit =
             self.gate
                 .try_acquire()