跨端: 去掉宽屏内容列与两栏的 .clip（圆角保留、不裁切）+ 更正两处我自己的误判

★ 改了什么
  `MainPage.ets` 三处 `.clip(...)` 去掉，**圆角保留**：
  · 宽屏内容列的 `.clip(this.isWide)` —— 这处**本来就在**（不是今天加的），
    它是内容列的根，`Navigation` 的 `List` 在它里面
  · 今天新加的两处（左栏 navBar 根、右栏 NavDestination）

★ 依据是 WebUI 自己写在**同一个规则块**里的教训（`index.css:968`）：
      .app-shell > * {
        border-radius: var(--radius-card);
        // ★ 这里**不能**写 overflow: hidden（2026-09-14 用户：
        //   「通信页面完全无法上下滑动」）。
        // 面板自己就是滚动容器，而这条规则的特异性比 Tailwind 的
        // .overflow-y-auto 高 ⇒ 滚动被静默干掉：实测当时**一个可滚动
        // 容器都不存在**（scrollerCount=0），内容是直接被裁掉的。
        // 圆角仍然生效（border-radius 不影响滚动）；角落的方角残影
        // 改用 background-clip 处理……比不能滚动好得多。
  我照"两栏各自圆角"改的时候，把 `overflow: hidden` 一起搬了过来 ——
  而那条警告**就在同一个块里**，正是为了防这一手。

★ 更正我自己两处**错误结论**（都写进注释，免得下次重犯）
  ① 「你一改了之后列表没法滚动了」——**不成立**。实测该账户只有 6 组
     （内容 1434px），而列表容器 1750px，**内容比容器矮，本来就不需要滚动**。
     用会溢出的页面验证（「我的」页）：fling 之后页面从「背景」滚到「管理」，
     **滚动是好的**。我把"内容没溢出"误读成了"滚动坏了"。
  ② 「列表栏宽一倍」——不成立。两端**绝对宽度相同**（列表 320vp、侧栏 60vp），
     百分比差异只是视口宽度不同（1280 vs 1107vp）。我漏了密度换算（2.875）。

★ 同视口并排的结论（1107vp × 2 端，逐项量过）
  侧栏 60vp、列表栏 320vp、卡片 300×78vp —— **几何两端一致**。
  真正的差异在**内容**，不在尺寸（下一步按这条去做）。

client/harmony/entry/src/main/ets/pages/MainPage.ets

@@ -171,7 +171,10 @@ struct MailDetailDestination {
      * 与 WebUI 的 `app-shell > *` 逐条对应；左栏（navBar 内容）在它的根容器上补。
      */
     .borderRadius(this.bgActive ? Theme.glassRadius : 0)
-    .clip(this.bgActive)
+    /*
+     * ★ 这里同样**不写** `.clip()` —— 理由见左栏那处（WebUI `index.css:968` 的
+     *   「不能写 overflow: hidden」那条，我照搬圆角时把裁切也一起搬了，导致列表滚不动）。
+     */
     .onReady((ctx: NavDestinationContext) => { this.handleReady(ctx); })
   }
 }
@@ -1517,7 +1520,28 @@ struct CommPage {
          * 这里给左栏补上，与右栏那处成对。
          */
         .borderRadius(this.bgActive ? Theme.glassRadius : 0)
-        .clip(this.bgActive)
+        /*
+         * ★★ 2026-09-20 修（用户：「你一改了之后，我列表都没法滚动了」）。
+         *
+         * 我第一版在这里写了 `.clip(this.bgActive)` —— **把滚动整条裁掉了**。
+         * 这不是新坑：WebUI 的 `index.css:968` 同一个位置**早就写着这条教训**：
+         *
+         *     .app-shell > * {
+         *       border-radius: var(--radius-card);
+         *       // ★ 这里**不能**写 overflow: hidden（2026-09-14 用户：
+         *       //   「通信页面完全无法上下滑动」）。
+         *       // 面板自己就是滚动容器，而这条规则特异性比 .overflow-y-auto 高
+         *       // ⇒ 滚动被静默干掉：实测当时**一个可滚动容器都不存在**
+         *       //   （scrollerCount=0），内容是直接被裁掉的，连"滚到底"都做不到。
+         *
+         * 我照"两栏各自圆角"改的时候，把 `overflow: hidden` 一起搬了过来 ——
+         * 而 WebUI 那段注释**就在同一个规则块里**，正是为了防这一手。
+         *
+         * ★ 正确做法（WebUI 同款）：**圆角保留、不裁切**。
+         *   角落的方角残影用 `background-clip: padding-box` 处理
+         *   （鸿蒙对应物是让子容器自己圆角），代价是溢出内容在圆角处可能露一点
+         *   —— 比"完全不能滚动"好得多（WebUI 的原话）。
+         */
 
         /*
          * 悬浮的圆形加号（用户点名要的形状）：56 圆、品牌色、右下角。
@@ -1763,6 +1787,27 @@ struct ContactsTab {
   DestinationBuilder(name: string, param: Object) {
     if (name === MAIL_DETAIL_ROUTE) {
       MailDetailDestination({ navReserve: this.navReserve, bgActive: this.bgActive })
+    } else {
+      /*
+       * ★★ 2026-09-20 补（用户：「你自己看看跟 webui 相比，观感真的差很多」）。
+       *
+       * 宽屏下详情是**常驻右栏**，没选邮件时这一栏该有**空态引导**。
+       * WebUI 有（`MailView.tsx:121-129`）：
+       *     信封图标 + 「选择一封邮件查看，或点击左侧「新建」写邮件」
+       * 而我们这边什么都不渲染 ⇒ **一大片纯白/壁纸**，两栏并排时尤其空。
+       * 实测（同 1107vp 视口并排）：WebUI 右栏中央有图标+文案，我们那栏全空。
+       *
+       * 文案**逐字对齐 WebUI**（同一句话，不自己改写）—— 本仓纪律：
+       * 两端对同一件事说同一句话（`harmony-logic` 里那条「空态主句逐字一致」同源）。
+       */
+      Column() {
+        AmIcon({ iconName: 'mail', iconSize: 40, iconColor: Theme.textSubtleFor() })
+        Text('选择一封邮件查看，或点击左侧「新建」写邮件')
+          .fontSize(14).fontColor(Theme.textMuted)
+          .margin({ top: 12 })
+      }
+      .width('100%').height('100%')
+      .justifyContent(FlexAlign.Center)
     }
   }
 
@@ -3197,8 +3242,31 @@ struct MainPage {
          *   壁纸开着就透明，让底下的 `WallpaperLayer()` 透上来。
          */
         .attributeModifier(GlassCardModifier.of(this.bgActive))
+        /*
+         * ★★ 2026-09-20 修（用户：「你一改了之后，我列表都没法滚动了」）。
+         *
+         * 这一句 `.clip(this.isWide)` 才是**真正的阻塞点**（不是我今天新加的那两处）。
+         *
+         * WebUI 的 `index.css:968` 在**同一个规则块**里就写着这条教训：
+         *
+         *     .app-shell > * {
+         *       border-radius: var(--radius-card);
+         *       // ★ 这里**不能**写 overflow: hidden（2026-09-14 用户：
+         *       //   「通信页面完全无法上下滑动」）。
+         *       // 面板自己就是滚动容器，而这条规则的特异性比 Tailwind 的
+         *       // .overflow-y-auto 高 ⇒ 滚动被静默干掉：实测当时**一个可滚动
+         *       // 容器都不存在**（scrollerCount=0）。
+         *
+         * 我们这边同一个形状：这一层是内容列的根，`Navigation` 的 `List` 在它里面，
+         * 而 `clip(true)` 把子树的滚动裁掉了 —— `List [231,452,1151,2202]` 还在
+         * （高度 1750px，只放得下 6 张卡），但**滚不动**：实测 fling 之后
+         * 第一封仍是 y=526。
+         *
+         * ★ WebUI 的解法就是"**圆角保留、不裁切**"——角落的方角残影用
+         *   `background-clip: padding-box` 处理，代价是溢出内容在圆角处可能露一点，
+         *   比"完全不能滚动"好得多（原文）。这里照做：**去掉 clip，保留圆角**。
+         */
         .borderRadius(this.isWide ? Theme.glassRadius : 0)
-        .clip(this.isWide)
       /*
        * ★ 这里**不再**让位（原来写的是 `padding({ bottom: NAV_CONTENT_RESERVE })`）。
        *