ui-theme: stable third-party theme manifest and listing API

[yohurm]

Context

Third-party themes register through ThemeRuntime.register() in-process, but there is no cross-package manifest contract and no list API, so a theme marketplace cannot validate or enumerate installed themes without executing them.

Proposal

A minimal static theme manifest (id, package/wiring id, --dsw-alias-* palette per mode, contrast declarations) read without executing code, plus a listing API over registered themes.

Why

YoDsh ships a theme catalog and validates palettes/contrast statically; the validation is duplicated because the runtime registry exposes no manifest.

[zoahdev]

核验通过（HEAD 99f6f02）：主题服务在 @deepseek-ai/dsh-client-ui-theme（client 端），提供 register（返回 disposer）/ getTheme / setTheme / theme/change 事件 / overrideTokens 堆叠——"in-process 注册、无静态清单、无枚举 API"的描述准确（枚举需要执行注册代码或维护运行时注册表）。

两点补充：

1. "read without executing" 是正确的安全原则，值得写进提案成为硬性要求

你提的"静态清单不做代码执行就能读取"与 awesome-dsh-plugin 收录 gate 的设计完全一致（pr-gate 用 git archive 提取 yml、只当数据处理、绝不执行插件代码）。建议把这条从设计偏好升级为规范约束：清单必须是纯数据（无 JS 求值、无 import），市场/验证器才能安全枚举。这也让主题清单天然能挂到 #3192 的内容完整性（L1）上——静态清单本身就是可哈希、可签名的单元。

2. 清单字段建议对齐 ThemeRegistry 的既有语义

--dsw-alias-* palette / contrast 之外，建议补两个运行时可读但不执行就能拿到的字段：id（注册 id）+ wiring id（package 名），这样市场验证清单与 register(id, ...) 实际注册的 id 能一一对应，静态枚举和运行时状态不会漂移（正是你"validation 重复"的根源——清单与运行时各说各话）。

方向支持，且这个提案成本低（纯数据契约 + 一个 list API），比 #3165/#3167 更容易先落地。