G22b, part one: the reads delivery needs, against a caller's connection

G22b, part one: the reads delivery needs, against a caller's connection Delivery resolves its tenant from configuration because its reads cannot be scoped any other way: `rights::effective`, `shares::is_live` and `derivatives::mark_served` each take a `&PgPool` and acquire from it, and `search_path` is set on a transaction rather than on a pool. A function that acquires its own connection reads whichever schema the pool defaults to, which is why the delivery pool has to be pinned to one tenant. So each grows an `_on` variant taking `&mut PgConnection`, following the convention thirty-five other functions in this crate already use. The pool-taking forms stay and delegate, so no existing caller changes. `rights::effective_on` is the one that needed a decision rather than a signature. `effective` is a cache read and, on a miss, an evaluation that writes the row — `evaluate_on` already existed, `cached` did not have a connection form. Running both on the caller's connection means a miss writes `rights_evaluations` inside the caller's transaction, so the row becomes visible on commit rather than immediately. That is the right trade here: the verdict is re-derived per request anyway, and a cache row landing a moment later is cheaper than a verdict read from the wrong schema. Written down at the function, because it is the kind of thing that reads like an oversight later. Plus `provision::slug_of`, the reverse of `find`: a claim carries a tenant id and scoping a request needs the slug naming its schema. `status = 'active'` is in the query rather than left to the caller — a suspended tenant's outstanding URLs should stop working, and a separate check is one somebody forgets in the path where forgetting it serves bytes. No behaviour changes yet. The handler is part two.