Fix the loop stalling after compaction, add an external registry

The compaction bug, which is the important one:

beta.2 taught the pruner to drop any assistant part whose reasoning item it had
removed. That was right about the 400 and wrong about everything else. On a
reasoning model every tool call carries a provider itemId, so past the threshold
the model could no longer see what it had already run, and re-ran the same tools
until maxSteps ended the turn. Reproduced at 12 model calls for a job needing 4,
with nothing but the user message reaching the wire.

The dependency is not the part, it is the itemId. A part carrying one is
serialised as `{ type: 'item_reference', id }`, a pointer to an item stored
provider-side that depends on its reasoning item. Without the itemId the same
content goes out inline and carries no dependency at all. Verified against the
provider's own serialiser: `text` with an itemId becomes item_reference, the
identical part without one becomes output_text.

So `dropOrphanedItems` becomes `detachOrphanedItems`: strip the itemId, keep the
content. Compaction may shorten the history; it must not blank it. The new test
asserts behaviour rather than shape — the loop must end because the model chose
to, and every call after the first must still carry the earlier exchange. A shape
assertion passed the whole time the model was losing its memory.

Registry, via `/registry [list|search|add|remove|installed]`:

Skills and plugins are treated differently on purpose. A skill is prompt text, so
installing one puts a stranger's words into the system prompt of every future
session in this project; the install shows the body first and the origin is
recorded, so /skills always says where an instruction came from. A plugin is a
JSON manifest of deny rules, evaluated by compiled code identical for every
install. Loading TypeScript from a URL is declined outright: a plugin that can
block tool calls could otherwise lie about blocking them.

Validated before anything is written: https only (file: and data: rejected), name
matched against ^[a-z0-9][a-z0-9-]*$ so it cannot escape its directory, size
caps on index and body, every regex compiled, pattern length capped since it runs
on every tool call, and the body's own name checked against the index. Installed
skills rank below your own, so an install can never shadow a skill you wrote.

Interface:
- Context is a percentage of the compaction threshold, amber from two thirds and
  red at 90. A turn about to lose history now says so beforehand.
- Aligned command menu and registry tables; /skills and /plugins name origins.

538 tests, up from 488. The registry is tested against a real local HTTP server,
and the guard is proven to refuse a .env write end to end rather than assumed to.

docs/memory.md

@@ -139,17 +139,25 @@ Pruning breaks two provider invariants. `src/prune.ts` repairs both, and both we
 before it did.
 
 **A message without its reasoning item.** `pruneMessages({ reasoning: 'all' })` strips a
-reasoning item and keeps the message item from the same response. The OpenAI responses API
-treats the message as a dependent of that reasoning item and rejects the request:
+reasoning item and keeps the message item from the same response. That message carries a
+provider `itemId`, and the OpenAI responses provider serialises anything with one as
+`{ type: 'item_reference', id }` — a pointer to an item stored on their side, which depends on
+the reasoning item that is now gone:
 
 ```
 400 Item 'msg_…' of type 'message' was provided without its required 'reasoning' item: 'rs_…'
 ```
 
 The two carry different ids, so they cannot be matched by id. What links them is the
-assistant message they arrived in — one message is one response. `dropOrphanedItems` drops the
-dependent parts of any turn whose reasoning was removed. That costs nothing, because pruning
-was already discarding those turns.
+assistant message they arrived in — one message is one response. `detachOrphanedItems` strips
+the `itemId` from those parts. Without one the same content is serialised **inline**, which
+carries no dependency on anything stored, so the turn survives intact.
+
+Dropping the parts instead was the first attempt, and it was wrong in a way that only showed
+up over a long turn: on a reasoning model every tool call carries an itemId, so after the
+first compaction the model could no longer see what it had already run. It re-ran the same
+tools until the step limit ended the turn. The history is the model's memory; compaction may
+shorten it but must not blank it.
 
 **A tool result without its tool call.** `toolCalls: 'before-last-3-messages'` counts
 *messages*, not pairs, so the cut can land between the assistant message holding a `tool-call`