Follow-up from the #38 review. `ctx.storage` capped each value at 8 MB and
bounded nothing else: no way to enumerate keys, no way to remove rows for a
module that was deleted or renamed, and `updated_at_ms` written on every set
and read by nothing.

`ModuleKv` gains `list`, `usage` and `deleteAll`. Sizes are `strlen`, not
`length` — DuckDB's `length` counts characters and the cap in `set` is in
UTF-8 bytes, and two units for one number is how a 3 MB value reads as 1 MB.

`ctx.storage.list()` is the module-facing half: its own keys, with sizes and
write times, never values — asking what you hold must not cost the whole
footprint to answer. It takes no module argument, like every other method on
the facade, which closes over the module's own name. A module still cannot
name another module's rows, and a test now proves that through a real
`register(ctx)` rather than through the store underneath it.

Dropping a whole module's rows is deliberately NOT on `ctx`. The rows most in
need of dropping belong to a module that no longer loads and therefore has no
`ctx` at all, so it is an operator action: `/system` gains totals per module,
a per-module key list, and a two-click clear behind `adminOnly` and CSRF, with
the delete logged. `configured: false` marks a module the deployment no longer
asks for — the case the whole issue is about, invisible on every other surface.

Never automatic on a load failure, per the review: a repo that could not clone
this boot is absent for a reason that resolves itself, and deleting its state
would turn a network blip into permanent data loss.

The optional per-module total bound is deliberately not here. It wants a
number, and the enumeration this adds is what will supply one from a real
deployment instead of a guess.

Verified against a running instance with seeded rows: the section renders,
the key drill-down expands, and the two-click clear removes one module's rows
and refreshes the totals with the database agreeing.

Closes #39

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@@ -342,0 +344,4 @@
+  // never the values: this is a diagnostics page, and a module's stored state
+  // can be anything it derived, including data its own UI gates on a role.
+  api.get(
+    "/system/module-storage/:module",

@@ -244,0 +250,4 @@
+   * module's own name (see `contextFor`), and that closure is the whole
+   * mechanism keeping one module out of another's rows.
+   */
+  get moduleStorage(): ModuleKv {

@@ -40,0 +51,4 @@
+  keys: number;
+  bytes: number;
+  /** most recent write, or null for a module holding nothing */
+  updatedAtMs: number | null;

@@ -95,0 +178,4 @@
+    // counted first: DuckDB's DELETE reports nothing back through `run`, and
+    // "removed 0 rows" versus "removed 40" is the whole confirmation the
+    // operator gets
+    const [row] = await this.db.query<{ keys: number }>(

@@ -105,0 +123,4 @@
+  // URL rather than by module name, so the name it stores under is only
+  // knowable from a load or a failure. A repo that could not clone this boot
+  // has not stopped being ours, and its rows must not read as orphaned.
+  const known = new Set([

@@ -105,0 +128,4 @@
+    ...host.loaded.map((m) => m.name),
+    ...host.failed.map((f) => f.name),
+  ]);
+  const usage = await deps.kv.usage().catch(() => []);

@@ -128,0 +182,4 @@
+  async function clearStorage(module: string) {
+    busy = true;
+    try {
+      const res = await coreFetch(

@@ -325,0 +475,4 @@
+            </div>
+            {#if !row.configured}
+              <div class="source">
+                Nothing configured under this name — rows left by a module that

@@ -342,0 +352,4 @@
+    async (c) => {
+      const keys = await host.moduleStorage.list(c.req.param("module"));
+      return c.json({
+        keys: keys.slice(0, KEY_LIST_LIMIT),

@@ -167,0 +173,4 @@
+    // orphaned. First-ever failures have no checkout; the slug stands.
+    if (!nameFromManifest) {
+      try {
+        name = (await readManifest(srcDir)).name;

@@ -350,1 +371,4 @@
         name,
+        // the manifest read is the first step, so any later stage means the
+        // name above came from it
+        nameFromManifest: stage !== "manifest",

@@ -24,3 +30,4 @@
     const ip = c.req.header("x-forwarded-for")?.split(",")[0].trim() ??
       "local";
     const now = Date.now();
+    if (buckets.size > SWEEP_ABOVE) sweep(now);

@@ -128,0 +209,4 @@
+      const fresh = await coreFetch("/api/core/system").catch(() => null);
+      if (fresh?.ok) {
+        info = await fresh.json();
+        clearError = null;

@@ -342,0 +351,4 @@
+    adminOnly,
+    async (c) => {
+      const module = c.req.param("module");
+      const keys = await host.moduleStorage.list(module, KEY_LIST_LIMIT);

@@ -128,0 +212,4 @@
+      // came from the /system snapshot, and a running module may have written
+      // since — "removed 41" when the button said 40 is exactly the kind of
+      // thing an operator should get to see
+      const { removed } = await res.json();