feat(modules): re-enable the inboundDocuments module

inboundDocuments leaves CODE_DISABLED_MODULE_KEYS (parked there since
v1.25.3). The normal two-layer resolution applies again: the module ships
dark (opt-in, per-user default off) and an operator false still disables
it server-wide; nothing becomes user-visible without an explicit opt-in.
The gate tests now pin the re-enabled behaviour instead of the hard-off
short-circuit.

Task: W1-T2.

src/lib/modules/__tests__/gate.test.ts

@@ -374,22 +374,21 @@ describe("registry — opt-in marker", () => {
   });
 });
 
-describe("resolveModuleEnabled — inboundDocuments module (disabled in code)", () => {
-  // v1.25.3 — `inboundDocuments` is switched off in code pending a rebuild
-  // (`CODE_DISABLED_MODULE_KEYS`). It is hard-off ahead of both the operator
-  // and the per-user layer: no stored preference or availability blob can
-  // re-surface it. The registry entry + `optIn` marker stay intact.
-  it("is flagged as code-disabled in the registry", () => {
-    expect(isCodeDisabledModule("inboundDocuments")).toBe(true);
+describe("resolveModuleEnabled — inboundDocuments module (document vault)", () => {
+  // Parked in code from v1.25.3; the document vault re-enabled it. Normal
+  // two-layer opt-in resolution applies again: dark by default, ON only on
+  // an explicit per-user opt-in, and an operator `false` still wins.
+  it("is no longer flagged as code-disabled in the registry", () => {
+    expect(isCodeDisabledModule("inboundDocuments")).toBe(false);
   });
 
-  it("is OFF when no preference is recorded", () => {
+  it("is OFF when no preference is recorded (opt-in ships dark)", () => {
     expect(
       resolveModuleEnabled("inboundDocuments", inputs(), false, ALL_AVAILABLE),
     ).toBe(false);
   });
 
-  it("stays OFF even when the user opted in (the in-code switch wins)", () => {
+  it("is ON when the user opted in", () => {
     expect(
       resolveModuleEnabled(
         "inboundDocuments",
@@ -397,16 +396,16 @@ describe("resolveModuleEnabled — inboundDocuments module (disabled in code)",
         false,
         ALL_AVAILABLE,
       ),
-    ).toBe(false);
+    ).toBe(true);
   });
 
-  it("stays OFF when the user opted in and the operator left it available", () => {
+  it("stays OFF when the operator disabled it, even with a user opt-in", () => {
     expect(
       resolveModuleEnabled(
         "inboundDocuments",
         inputs({ modulePreferences: { inboundDocuments: true } }),
         false,
-        operator({ inboundDocuments: true }),
+        operator({ inboundDocuments: false }),
       ),
     ).toBe(false);
   });

src/lib/modules/registry.ts

@@ -338,12 +338,12 @@ export function isModuleKey(key: string): key is ModuleKey {
  * migration) stays intact — re-enabling the module is a one-line removal
  * from this list once the rebuild lands.
  *
- * v1.25.3 — `inboundDocuments` is parked here: the inbound-documents surface
- * is withdrawn from this release and returns later with more depth. Its
- * registry entry, `optIn` marker, routes, view, and migration 0222 are all
- * preserved; only the user-reachable switches are removed.
+ * Currently empty. `inboundDocuments` was parked here from v1.25.3 until the
+ * document vault re-enabled it (per-user opt-in + operator availability
+ * resume their normal two-layer resolution; the module still ships dark by
+ * default via `optIn`).
  */
-export const CODE_DISABLED_MODULE_KEYS = ["inboundDocuments"] as const;
+export const CODE_DISABLED_MODULE_KEYS = [] as const;
 
 const CODE_DISABLED_MODULE_SET: ReadonlySet<string> = new Set(
   CODE_DISABLED_MODULE_KEYS,