功能开发：Ubuntu26.04截图OCR
功能逻辑链路：
Print ──> GNOME 原生 ScreenshotUI（冻结帧 + 工具栏）
│ 扩展往 _typeButtonContainer 里塞了第 4 个按钮
▼
点「提取文字」──> 藏掉原生选区的遮罩 + 四角把手，得到干净画面
▼
拖拽框选 ──> 松手（UIAreaSelector 的 drag-ended 信号）
▼
UIAreaSelector.getGeometry() → [x, y, w, h] 逻辑坐标
▼
_stageScreenshot.get_content().get_texture() 冻结帧，不是实时屏幕
▼
Shell.Screenshot.composite_to_stream(tex, x·scale, y·scale, w·scale, h·scale, …)
▼
Gio.MemoryOutputStream → PNG 字节（内存里裁，不走 portal、不弹权限）
▼
落一个临时 PNG ──> Gio.Subprocess([‘ocr’, ‘–quiet’, 路径])
▼
客户端 ──Unix socket──> 常驻 ocrd 进程（RapidOCR + ONNX Runtime）
▼
stdout = 文字 ──> St.Clipboard 写剪贴板 ──> 通知 ──> ui.close()
四个关键点：
1. 为什么只能碰私有 API。 GNOME 没给截图 UI 留扩展点；org.gnome.Shell.Screenshot 的 D-Bus 方法又被 _senderChecker 白名单挡着（只放行 gsd-media-keys 和 portal 后端），扩展自己调必然 AccessDenied。唯一出路是 Main.screenshotUI 这个已经存在的对象——直接改它的字段。所以每处访问都带存在性判断，字段没了就退化成提示，不崩 shell。
2. 为什么取像素不重新截屏。 UI 一打开就已经有一张冻结帧了。直接拿它的 texture 按选区裁剪，零延迟、不会把 UI 自己拍进去、也不经过 portal。重新截屏就得多一次系统调用 + 权限判定。
3. 为什么引擎要常驻。 RapidOCR 加载 ONNX 模型约 3.8 秒。放进 systemd 用户服务（ocrd）后冷启动只付一次；之后每次只算推理——420×120 小图 ~100ms，1080p 整屏 ~2.5s。客户端只负责 socket 收发。
4. 独立框选是”借”出来的。 点击按钮后把 _areaIndicator（四周压暗遮罩）和 4 个 screenshot-ui-area-selector-handle 全部 hide()，屏幕就只剩干净画面；一开始拖拽，drag-started 再把它们 show() 回来做实时反馈——这就是它不像在和原生选区模式共用的原因。
注意：原生代码从不改这 5 个 actor 的可见性，所以恢复的责任全在扩展这边。disable()、用户取消、OCR 成功、OCR 出错——四条路径都必须还原，漏一条就会把原生截图界面弄坏。
实际截图：
