fix(mem): 内存口径定案 —— BASE 448 / MIN 448 / MAX 1024（用户裁定）

用户裁定：「base 448 没问题 max 就是 1024」。据此把两侧常量收成一份事实
（编排器 instanceMemMb() 与插件客户端 MEM_* 必须逐值一致，verify-mem-model 会守着）：

· BASE 160 → 448：0.1.5 基座**实测 312 MiB**，旧值按 0.1.2 的 106~145 估的、严重低估
  ⇒ 384 的上限里只剩 72 MiB 给插件，这正是宿主 swap 被吃掉（452 MiB）的原因
· MIN 384 → 448：**MIN 必须 ≥ BASE**，否则 clamp(raw, MIN, MAX) 的下限失去意义
  （旧 384 在 BASE=160 时满足该不变量，抬 BASE 后必须跟着抬）
· MAX 1536 → 1024：不是偏好，而是编排器头部既有的不变量
  「上限 1024M 是单实例硬顶（宿主 1870M）」；在途草稿的 1536 与宿主容量前提自相矛盾
· mcn 成本表保持 128（驳回草稿的 256）：无可支撑抬高的实测，反向有证据 ——
  装了它的用户在旧 384 上限下一直跑得住 ⇒ 需求 ≤384；而抬高会直接吃宿主余量

实测（铺发+重启后经 /api/dsh/status 核对）：admin 384→576、guest 384→448，
均在 [448,1024] 内；heapMb 256；两实例 restarts:0。宿主可用 761→1267 MiB。
本机 verify-mem-model 与 npm run verify 均**首次全绿**。

插件 business-plugins 0.3.16 → 0.3.17（客户端常量随之更新）。

poc/business-plugins/lib/client.js

@@ -94,10 +94,11 @@ window.__ModuleLoader__.load({
 		//   而平台真实配额是 672（guest）/ 384（admin），**384 早已只是下限** ⇒ 纯属误报。
 		//   修法：① 常量与规则对齐平台；② 优先读 `/api/dsh/status` 的 `quota.memMb/heapMb`
 		//   （平台**实际使用**的值）直接显示；③「超限」改为判断是否顶到硬顶 MAX。
-		/** 与编排器 `BASE_MEM_MB` 一致。 */
-		var MEM_BASE_MIB = 160;
-		/** 与编排器 `MIN_MEM_MB` 一致 —— ⚠️ 这是**下限**，不是上限。 */
-		var MEM_MIN_MIB = 384;
+		// 2026-09-14 定案（BASE 448 / MIN 448 / MAX 1024）：与编排器 instanceMemMb() 是**同一份事实**，两处必须逐值一致； scripts/verify-mem-model.mjs 会逐键比对。
+		/** 与编排器 `BASE_MEM_MB` 一致。0.1.5 基座实测 312 MiB ⇒ 抬到 448（旧值 160 按 0.1.2 的 106~145，严重低估）。 */
+		var MEM_BASE_MIB = 448;
+		/** 与编排器 `MIN_MEM_MB` 一致 —— ⚠️ 这是**下限**，不是上限；**必须 ≥ BASE**，否则下限失去意义。 */
+		var MEM_MIN_MIB = 448;
 		/** 与编排器 `MAX_MEM_MB` 一致 —— 单实例硬顶。 */
 		var MEM_MAX_MIB = 1024;
 		/** 与编排器 `PLUGIN_MEM_MB` 一致；未识别的插件平台按 0 计。 */