优化长连续声母输入的有界缩写解码

[0x1b2c]

背景

当前连续声母输入已经支持短缩写，例如 js、rgzn、zryy 等。但当输入变成长连续声母串，例如 jsjsjsjsjsjs，现有算法可能在输入法主线程上出现严重卡顿，甚至造成输入法短时间不可用。

系统拼音在类似输入下可以持续动态组词，说明正确目标不是简单放弃长连续声母组词，而是需要为这类输入设计有界、增量、可控的解码算法。

现状分析

当前 Conversion.compose 是从右向左的 DP，并在每个位置调用 enumeratePhrases 枚举可能片段。对普通拼音输入，这种搜索空间通常可控；但对连续声母输入，每个声母都可能展开成大量合法音节，并且还会继续探测后续组合。

这会导致搜索空间随输入长度快速增长。局部 SQL LIMIT 只能限制单次查询结果，无法从根本上约束 DFS 分支数量。因此这个问题不应仅通过给数据库查询补上限来解决。

期望方向

为连续声母输入增加专门的 initial-only decoder，而不是继续把长缩写交给通用 Conversion.compose 的 DFS 展开路径。

候选方向：

• 将连续声母输入建模为有限候选边组成的格图，而不是枚举所有拼音展开；
• 使用 beam search 或类似有界搜索机制，按位置增量维护少量高质量路径；
• 限制每个位置可产生的候选边数量，区分单字、二字词、三字及以上词；
• 限制 beam 宽度，使复杂度接近「输入长度 × 每位置候选边数 × beam 宽度」；
• 长连续声母仍应支持整句级动态组词，而不是退化成只处理前缀；
• 输出结构尽量复用 ConversionResult，使上层候选逻辑可以继续工作。

约束

• 不应牺牲短缩写现有行为，例如 js、rgzn、zryy；
• 不应在输入法主线程执行无界 DFS 或无界数据库扫描；
• 长连续声母输入必须有确定的时间上界；
• 未来候选语义结构化之后，应能表达整串候选、局部候选、前缀确认候选等不同语义。

验收建议

• jsjsjsjsjsjs 等长连续声母输入不会造成输入法卡顿；
• 短缩写回归测试保持通过；
• 长连续声母可以产生合理的整句级候选，而非仅返回首段候选；
• 增加性能测试或压力测试，覆盖连续声母长度增长场景。