跨端: 上下黑边真的消了 —— 全屏 + 避让是"同一套东西的两半"，上次只删了一半

用户第三次报同一条：「你再看看页面底部，那么大的黑色，你看从头到尾都没
修好，你能不能好好看看我给你的示例工程怎么处理上下黑边的」。

## 根因：上一次把"两半"当成了"一件事"，删掉一半就以为修好了

`6861934` 的注释白纸黑字写着「★ **刻意不用** `setWindowLayoutFullScreen(true)`」，
理由是「实测过：它确实也消掉黑带，但会连状态栏区域一起吃进布局，于是页签栏
被时钟/电量盖住（截图硬证「07:43」与「收件箱」重叠）」。

那次实测**是真的**，结论**下错了**：被盖住不是"不该全屏"，而是
**只做了全屏、没做避让**。示例工程里这两件事本来就是**同一套东西的两半**：

    common/.../util/WindowUtil.ets        → setWindowLayoutFullScreen(true)
                                          + getWindowAvoidArea(TYPE_SYSTEM /
                                            TYPE_NAVIGATION_INDICATOR)
    features/mine/.../view/MineView.ets:251 → .margin({ top: statusBarHeight + …,
                                                        bottom: naviIndicatorHeight })

只做前半 ⇒ 内容跑到状态栏底下没人让（那次退回的原因）；
只做后半 ⇒ 黑边照旧（这三次报修的原因）。退回的代价是**黑边留了三天**。

## 实测（模拟器 1256x2760，四页一致）

    修前：顶部纯黑 136px、底部纯黑 60px + 手势条 20px
    修后：四页**纯黑段均为 0**；y=0..135 是壁纸（时钟浮在上面，正是示例工程的效果）
          y=2662+ 壁纸铺到底、底栏浮在手势区之上

## 改了什么

- `entryability/EntryAbility.ets`：拆出 `setupFullScreenWindow()`，
  在 `loadContent` **回调里**调（与示例工程同一位置 —— `px2vp` 要用 `getUIContext()`，
  那要有已加载内容才拿得到）。全屏 + 读两个避让区 + 订 `avoidAreaChange`。
  `setWindowSystemBarEnable(['status'])` 保留（状态栏要看得见），但**不再靠它**消黑边。
- `model/WindowInsets.ts`（新）：纯逻辑 `insetsFromAvoidArea()`，不 import SDK ——
  判据才能在 node 里直接喂样本验换算。形参叫 `toVp` 而**不是** `px2vp`：
  后者是 SDK 已废弃的全局函数名，`harmony-system-api` 按名字扫，同名形参会误报。
- `pages/MainPage.ets`：`@StorageLink(KEY_WINDOW_INSETS)` 订阅；状态栏高度当
  **内容层**的 `padding-top`（**不是**根 Stack —— 壁纸必须铺到屏幕四边，根上加
  padding 会把壁纸一起缩进去，黑边只是换个地方出现）；底栏与内容末尾让开手势条。
  reserve 收成**一个** `recomputeNavReserve()`，宽度变化与避让变化两个触发点共用
  （转屏只改避让不改宽度，各写一份迟早漏一个）。

## 判据：`test/harmony-window.test.mjs`（8 条）

钉的是"两半必须同时存在"——**只钉一半的话，"退回某一半"照样能全绿通过**，
而那次退回恰恰就是删了一半。纯逻辑 3 条（换算/取不到就是 0 不猜/键名是常量）
+ 接线 4 条（全屏在、避让在、布局真消费了值、纯逻辑模块不许 import SDK）
+ 设备行为 1 条（全屏没把应用搞成白屏）。

**变异自检两个方向都跑过**（这是本轮最该记的一步）：
- 删掉 `setWindowLayoutFullScreen`（重演 6861934）⇒ 2 条红 ✓
- 删掉 `getWindowAvoidArea`（只全屏不让位）⇒ 1 条红 ✓

★ 第一版判据**锚错了**：正则直接扫全文，而注释里正好有 `setWindowLayoutFullScreen(true)`
  这个串 —— 把真正的调用删掉后判据**仍然全绿**。锚落在"代码对自己的描述"上了。
  加 `stripped()` 剥注释后，变异才咬得住。这条与仓里那条"判据的锚不能落在
  被守对象的自述上"是同一件事，这次是它的实例。

## 顺带修的两条既有判据（不是放宽，是它们把"当时的字符串"当成了"要守的坑"）

- `harmony-nav` ④：留白断言写死了 `bottom: NAV_BAR_BOTTOM` 那个字面串。
  它本来要守的是"留白靠 padding 不靠 margin"（margin 在 ArkUI 里加在宽度外面，
  100% + margin 会顶出父容器）—— 那是另一件事。改成剥注释后验三段在不在、
  离底是否**从** `NAV_BAR_BOTTOM` **起**。变异（padding→margin）仍判红 ✓
- `harmony-widescreen` ④：同上，写死了 `? 0 : NAV_CONTENT_RESERVE`。
  改成"宽屏必为 0、窄屏含 NAV_CONTENT_RESERVE（可再加避让）"。

两处都是"加一个正当的避让"与"真犯那个错"会红得一模一样 —— 那就不再是守坑，
是守字符串。

另：`align-refs` / `build-stamp` / `packaging` 三条 broken 是前端 `99a2d7a`
（另一个人改的 `CalendarView.tsx`）带来的，与本轮无关，留给他。

client/electron/test/harmony-widescreen.test.mjs

@@ -91,9 +91,19 @@ test('④ MainPage 接线：宽屏才挂侧栏、宽屏藏底部条、断点 768
    * ★ 2026-09-17：让位方式改了 —— 宽屏不再靠"内容 padding 归零"，
    * 而是宽屏时 navReserve 本身变成 0（没有底部条）。
    * 内容窗格必须**满高**，否则内容滑不到条底下、玻璃就没东西可糊。
+   *
+   * ★ 2026-09-18：窄屏那一支多加了 `windowInsets.navIndicator`（全屏后要让开系统
+   * 手势条，见 `harmony-window.test.mjs`）。所以断言改为：**宽屏一定是 0**，
+   * 窄屏是 `NAV_CONTENT_RESERVE` **加上避让**（不是写死那个字面表达式）。
+   * 写死的话，"加一个正当的避让"与"宽屏忘了归零"会红得一模一样 ——
+   * 而这条判据要守的是后者。
    */
-  assert.match(code_, /this\.navReserve = this\.isWide \? 0 : NAV_CONTENT_RESERVE/,
-    '宽屏时 navReserve 要归零（没有底部条，列表不需要为它让位）');
+  const reserve = /this\.navReserve = this\.isWide \? 0 : ([^;]+);/.exec(code_);
+  assert.ok(reserve, '要按 `isWide ? 0 : <窄屏值>` 的开关式写 navReserve');
+  const narrowExpr = reserve[1].trim();
+  assert.notEqual(narrowExpr, '0', '窄屏不能归零（窄屏有底部条，列表要让位）');
+  assert.match(narrowExpr, /NAV_CONTENT_RESERVE/,
+    '窄屏要让条高那么大的位（至少含 NAV_CONTENT_RESERVE）');
 });
 
 test('⑥ 邮件列表→详情使用系统 Navigation Auto，不再手搓 Row 分栏', () => {