fix(mem): 统一实例内存配额口径 + status 暴露真值（消灭「388 MiB」误报）

用户问「实例内存大小是不是调整过了，为什么功能设置中还是显示 388 多」。
实测：guest 真实 MemoryMax = 672 MiB、admin = 384 MiB（都真调整过）；
而「功能管理」显示的是插件**自建的第二套模型**（基线 285 / univer 64 / mcn 39，
且把 clamp 下限 384 当硬上限）⇒ 全勾显示 388 并报「⚠ 将超出上限」，纯误报。
根因：档案 81 R1 把「写死 384」改为「按插件集合推导」时**只改了编排器**，
插件那份副本原地漂移，此后 univer 384→512、mcn-suite 128 都没同步。

平台侧（把已算好的真值透出来，零新增计算）：
- spawner.ts 新增可选 quotaInfo?(userId)（照 breakerInfo 模式）
- orchestrator.ts 实现 quotaInfo()，走**同一个** instanceMemMb()/heapMbFor()
- /api/dsh/status 返回 quota: {memMb, heapMb}

防漂（根因是「同一事实两处副本」，必须让它不可能再漂）：
- 新增 scripts/verify-mem-model.mjs，逐项交叉断言常量/成本表/clamp 算式/接线点，
  接进 npm run verify —— 任一处漂移即构建失败（已做反向验证：改回 285 即 exit 1）

验证：build 零报错；verify 全绿（含新增 15 项断言）；服务端 md5 与本机编译产物一致；
GET /api/dsh/status → quota {memMb:384,heapMb:256} 与实测 402653184 吻合。

注：poc/business-plugins/**（0.3.6）与其 package.json 未在此提交 —— 该文件被并行会话
连续改过两轮（0.3.4/0.3.5，0.3.5 已上线但未 commit），刻意留给他们一起提交。

src/supervisor/orchestrator.ts

@@ -918,6 +918,25 @@ export class LocalSpawner implements Spawner {
     return { opens: b.opens, openedAt: b.openedAt, cooldownUntil: breakerUntil(b, this.breakerPolicy()) }
   }
 
+  /**
+   * 档案 84 观测面：把「本实例实际拿到的内存配额」透出来 —— 与 spawn 时用的是**同一个**
+   * `instanceMemMb()` / `heapMbFor()`，因此不可能与实际 `MemoryMax` 对不上。
+   *
+   * 为什么需要它：实例内的客户端插件（`business-plugins` 的「功能管理」）看不到 cgroup，
+   * 过去只能自建一套估算表 —— 而第二份副本**必然漂**（2026-09-13 实测：插件显示 388 MiB
+   * 并报「⚠ 将超出上限」，而平台真实配额是 672 / 384，且 384 早已只是**下限**）。
+   * 与其让第二份副本再漂一次，不如把已有值暴露出去、让前端读真值。
+   */
+  quotaInfo(userId: string): { memMb: number; heapMb: number } | null {
+    try {
+      const profileDir = join(userRoot(this.config.dataRoot, userId), 'home', 'profiles', 'web')
+      const memMb = instanceMemMb(profileDir)
+      return { memMb, heapMb: heapMbFor(memMb) }
+    } catch {
+      return null
+    }
+  }
+
   /** 清空某用户的崩溃计数（显式启动 / 人工重启 / 停机时调用）。 */
   private resetCrashState(userId: string): void {
     this.crashHistory.delete(userId)

src/supervisor/spawner.ts

@@ -112,6 +112,13 @@ export interface Spawner {
    */
   breakerInfo?(userId: string): { opens: number; openedAt: number; cooldownUntil: number } | null
 
+  /**
+   * 档案 84：实例内存配额观测面（可选 —— 「配额随插件集合推导」是**本地模式**概念）。
+   * 返回 `instanceMemMb()` / `heapMbFor()` 的**同源结果**，供实例内的「功能管理」
+   * 直接显示真值，而不是各自维护一份必然会漂的估算表。
+   */
+  quotaInfo?(userId: string): { memMb: number; heapMb: number } | null
+
   /** Restart every running main so a swapped global API key takes effect (env is a spawn-time snapshot). */
   restartAllMains(): Promise<void>
   spawnWatchdog(userId: string): Promise<Instance | undefined>

src/web/routes/dsh.ts

@@ -176,6 +176,9 @@ export const dshRoutes: FastifyPluginAsync = async (app) => {
       watchdog: watchdog ? { id: watchdog.id, status: watchdog.status, exitCode: watchdog.exitCode } : null,
       // 观测面（档案 78）：熔断状态 —— 非 null 即"该用户正被冷却"，供门户/排查直接看到
       breaker: app.supervisor.breakerInfo?.(request.user!.id) ?? null,
+      // 观测面（档案 84）：本实例**真实**内存配额（= instanceMemMb() 的结果，与 spawn 同源）。
+      // 实例内「功能管理」读它显示真值；读不到（老平台/ k8s 模式）时前端才退回保守估算。
+      quota: app.supervisor.quotaInfo?.(request.user!.id) ?? null,
       url: dshUrl(app.config.baseDomain, request.user!, main?.launchToken),
     }
   })