db: read a database's timestamps out of the store

The repository table has carried created and updated since the first
migration and the projection never selected them, so core.Repo could not
answer when a database was made. Nothing needed it while the surfaces were
pages: a listing sorts by created in SQL and prints none of it.

/query publishes a database as a record rather than as a page, and a record
without its timestamps is a poorer answer for no reason — the columns are
already there. CreateRepo returns the pair it wrote, so a caller need not
re-read the row to learn them.

The test reads them back through all three projections. A column dropped
from repoSelect would otherwise surface as the zero time for every database
on the instance, without failing anywhere.

web: rename a database from its settings page

A database's name lives in two places — the metadata row and the on-disk
store directory its path names — so a rename has to move both. The order
is creation's: the row first, where a name already taken is refused by the
unique index before anything on disk changes, then the store, then the
handle the remotesapi memoized under the old path. A store that will not
move rolls the row back, so the two halves never disagree about where a
database lives; only a failed rollback is escalated to a human, because
it is the one outcome no later request can repair.

storage.MoveStore is one os.Rename behind the containment guard DeleteStore
already used, extracted here as containedPath. It refuses an occupied
destination outright: os.Rename over an empty directory would succeed and
swallow it.

No redirect is left behind — the old address simply stops resolving, as on
git.sr.ht — so an existing clone needs its remote replaced, and a companion
of a git repository is re-provisioned under its old name by the next push
to that repository. The README's quickstart now says both.

db: list every database a viewer may see

fix(db): map repository_path_key to ErrNameTaken

CreateRepo only recognized uq_repo_owner_id_name as a name collision, but
path is derived from (owner, name) by RepoDiskPath, so a duplicate always
violates both indexes -- and repository_path_key, declared inline on the
column, has the lower OID and is the one Postgres reports. ErrNameTaken was
therefore unreachable in practice and every duplicate surfaced as a raw
23505, breaking all three callers that branch on it:

  - /internal/repos returned 500 "create database" instead of an idempotent
    200, so git.sr.ht's post-update hook printed "companion provisioning
    failed (500)" on every push to a repo whose companion already existed
  - the web create form returned 500 instead of 409 "You already have a
    database with that name."
  - a lost remotesapi auto-create race failed with codes.Unavailable
    instead of adopting the winner's row

TestCreateRepoDuplicateName missed it by re-creating under a different
path, which only the name index catches; it is now table-driven over both.

rename module to sourcecraft.dev/bigbes/sr-ht-dolt; depend on sourcecraft sr-ht-core

db: postgres layer for repos, ACLs, dolt keys

Store wraps a Querier (*sql.DB/*sql.Tx/*sql.Conn); context-first methods, FromContext for core-go middleware, WithTx for the create-repo transaction. Repo CRUD + listing-visibility rules, effective-access/ACL upsert, dolt_key CRUD with typed ErrNotFound/ErrNameTaken/ErrKeyExists. Tests gated on DOLTSRHT_TEST_PG: per-run scratch schema + schema.sql, CRUD/visibility/effective-access cases; skip when unset.