web: render memory bodies as markdown, and resolve their references

A memory's value is markdown and always was: `bd remember` stores what was
typed, and what is typed is the same prose the memory files carry — bold
leaders, code spans, fenced recipes, and [[slug]] references to related
memories. The view printed it as pre-wrapped paragraphs, which shows the
source rather than the document and leaves every reference a dead end.

The renderer is web/markdown.go, one shared goldmark with three departures
from stock:

  - [[slug]] is an inline parser rather than a text rewrite, so a reference
    written inside a code span stays text by construction.
  - Raw HTML is escaped and shown, not dropped. The safe default omits it,
    and these memories are full of <placeholder> spellings CommonMark reads
    as tags; omitting one rewrites SRHT_<NAME>_VER to SRHT__VER silently,
    which is worse than showing markup.
  - An image renders as a link. An <img> at another host is a request that
    host makes on behalf of whoever opened the page.

References resolve across databases, because that is where they point: the
mirroring workflow files a memory by its type, so a related memory is as
likely to be in another tracker as in this one. The index is the one the
issue links already use — issue_prefix and the kv.memory.* keys are rows of
the same config table, so one read per database now answers both questions
and one cached projection carries both. A slug two trackers hold resolves to
the first listed, the page's own database, unlike a prefix two trackers claim
which resolves to neither: the same slug in two trackers is normally one
memory that was re-filed and left a copy behind.

A slug nobody wrote and a slug held by a database the caller may not browse
are one rendering — a muted, inert marker. A link, a distinct class or a
different tooltip would each publish the existence of a private database.

Memory.Paragraphs goes with the paragraphs it existed for.

web: link issue ids to the tracker that owns them

web: show how fresh a beads view is

handleView now reads the head commit of the rendered ref onto the envelope
(Head *browse.CommitInfo), and the beads and milestones headers carry a
shared beadsHead partial: <branch> · last commit <relative> · <short hash>,
the hash linking to the commit page and the exact stamp in the title.

The read is decoration on top of an answer: a database with no commits, or
a Log that fails, renders the page without the line rather than 500ing.

The relative time is a new ago func rather than chrome's reltime — it is
past-facing (clock skew reads as "just now", never "in 3 minutes") and
reads a package clock a test can pin.

web: render through ecore's pages and its error page

The page list, the per-page parse loop and the view-template loop are
gone: pages discovers every file in templates/, so a page is registered
by existing, and one that defines no content block is refused at startup
rather than served as chrome around a hole. 404.html and 403.html are
gone with them — the shared error page carries the same body, and its
prose is deliberately the same for a database that is not there and one
the viewer may not see.

The renderer that replaced them closes a leak: the old one wrote
"template render error: "+err.Error() into the response body, handing
the viewer template names and field paths. pages answers a fixed
sentence and returns the error for the log.

reltime and abstime come from chrome.Funcs now; ours called every future
instant "just now", where the shared one says "in 3 weeks".

web: draw the chrome from sr-ht-ecore

The brand, the service switcher, the login block, the environment banner
and the database listing were a local port of core.sr.ht's nav — one of
five such ports on this instance, and they had already drifted. They are
now sourcecraft.dev/bigbes/sr-ht-ecore/chrome, the one copy every custom
service draws from.

Deleted: web/chrome.go entire (navEntry, networkOrder, networkExcluded,
buildNetwork, basePage, loginURL, logoutURL), templates/nav.html,
templates/icons/circle.svg (ecore inlines the identical SVG), the
repoList partial, and the local dict/shortHash duplicates.

Added: one chrome.Service built in newApp from our config section with
the hashed stylesheet href set on it, a chrome.Page per request through
app.page, chrome.Attach on every template set, and chrome.Funcs as the
base of the funcmap. Handlers embed chrome.Page in their view structs
instead of copying its fields; the row browser sets ContainerClass to
container-fluid, since its column count is the table's and not ours.

Three behaviour changes come with ecore's policy, all deliberate: the
profile link now prefers hub's ~username page when hub.sr.ht is
configured (it was always meta's /profile), the brand carries a fixed
15rem min-width so the switcher starts at the same x on every service,
and a binary built without a stylesheet renders bare rather than linking
an empty href. The nav test went with the code it tested — ordering,
exclusions and login URLs are ecore's to cover — and what replaced it
asserts only what is ours: that pages are drawn through the chrome at
all, and that the row browser is full-bleed.

The auth path is untouched: a foreign bearer token is still accepted as
a meta.sr.ht PAT.

feat(web): pluggable alternative-view registry for repositories

A repository can now expose specialized, read-only "views" chosen by the
shape of its tables, while the generic table browser stays available as a
fallback. A View fingerprints the tables (Applies), builds a model from
the browse layer (Build), and renders its own template; views register at
init time via RegisterView and are dispatched by slug at
/~user/db/view/{slug}. The overview shows a tab per applicable view.

The template loader parses each registered view's template with the
shared chrome, so a new view plugs in by adding two files (its .go with
init()+RegisterView and its .html) plus nothing else — no edits to the
registry, router, loader, or handlers. Build receives the request query
values so a view can offer sub-modes (e.g. a detail pane). No SQL engine
is involved; views read through the existing BrowseSession surface.