fix: refuse the second registration, and say what leaves the machine

Two things the first cut got wrong.

Memorable's own installer registers the same UserPromptSubmit hook, under its
own name and outside gstack's table. `memorable start`, `memorable setup` and
`memorable install-hooks` all do it, and that is the documented way to install
the CLI, so on most machines it is already there before gstack is asked.
Registering ours beside it ran the same command twice on every prompt: context
injected twice, and the session captured twice against the user's own
extraction allowance. `enable` now looks for it and refuses, naming the entry
and the file it lives in; `status` says who registered it rather than reporting
none. Matched on the command rather than on a tag, for the reason the hook
table already gives: Claude Code rewrites settings and private tags do not
survive it.

The removal instruction says to delete the entry by hand because Memorable has
no command that removes its own hook. `uninstall-hooks` is not a command in
0.5.18; it answers "unknown command".

The README said "Memorable, not gstack, owns the captured data and any network
access", which answers the question by pointing away from it. It now carries a
per-command table of exactly what leaves the machine, in the shape the adopted
gbrain section uses, and it is explicit that the hook makes no network call of
its own, that every row is the third-party CLI acting under its own consent,
and that `gstack-egress` will therefore not show any of it. Under it, the split
between what gstack pin-tests (the gating and the wiring) and what is
Memorable's claim (storage, sending, and what disable and forget erase).

The CHANGELOG entry is removed. This file has never carried an [Unreleased]
heading; every entry is a version and a date, written at release. The text is
in the pull request for whoever cuts the next one.

Three tests added: enable refuses and touches neither consent nor settings when
Memorable already holds the hook, status names that registration, and a foreign
UserPromptSubmit hook is not mistaken for Memorable's.

(cherry picked from commit e0899afa8c)

README.md

@@ -311,6 +311,27 @@ The hooks fail open: if Memorable is missing or errors, Claude continues
 normally. This is recalled procedural guidance, not deterministic replay, and
 it is unrelated to Aside or browser automation.
 
+**Exactly what leaves the machine, per command this bridge can trigger.** The
+hook makes no network call of its own; every row below is the third-party CLI
+acting under its own consent, which is why there is no gstack egress receipt to
+read. `gstack-egress` will not show these.
+
+| Command | What leaves the machine |
+|---|---|
+| `command -v memorable`, `gstack-memorable status` | Nothing. Both are local reads. |
+| `gstack-memorable enable` | Nothing from gstack. It runs `memorable enable`, which records consent on your machine. |
+| the hook, on every prompt | The prompt text you typed, to Memorable's embed endpoint, when the local lexical match misses. Nothing else at prompt time. |
+| capture, at session end | Memorable's own hook, not this bridge and not gstack's consent. It sends the finished session's tool calls and their arguments to Memorable's extraction API under `memorable enable`. Turn it off with `memorable disable`. |
+
+**What gstack pin-tests, and what is Memorable's own claim.** gstack tests the
+gating and the wiring: that `enable` refuses when Memorable already registered
+the hook itself, that `disable` removes only gstack's entry and never a foreign
+one, that the hook exits zero and silent when the binary is missing, and that
+`status` writes nothing. Everything past the process boundary is Memorable's
+claim and not ours: what it stores, where it stores it, what it sends, and what
+`memorable disable` and `memorable forget` actually erase. The CLI is a
+closed-source npm package from a third party.
+
 ### Continuous checkpoint mode (opt-in, local by default)
 
 Set `gstack-config set checkpoint_mode continuous` and skills auto-commit your work as you go with a `WIP:` prefix plus a structured `[gstack-context]` body (decisions, remaining work, failed approaches). Survives crashes and context switches. `/context-restore` reads those commits to reconstruct session state. `/ship` filter-squashes WIP commits before the PR (preserving non-WIP commits) so bisect stays clean. Push is opt-in via `checkpoint_push=true` — default is local-only so you don't trigger CI on every WIP commit.