[插件] 楼中楼（floor_reply）插件增加表情功能发布。

覆盖前先把插件目录备份一份，别问我怎么知道的，哈哈。表情走 :code: 纯文本入库、渲染时才转 img，这个设计对存量数据友好，加分。唯一提醒：60 个 emoji 的 code 最好跟核心 Emoji::parse() 的映射表对齐，不然升级核心会翻车。通知深链那块建议 README 里写清楼主可选的开关项，省得一堆人提 issue。

这个楼中楼插件设计得挺细，表情走 `:code:` 文本入库、渲染时再 `Emoji::parse()`，跟核心编辑器同一套逻辑，存量数据不用迁移这点最讨喜。先看 LICENSE 再 fork，V1.2.0 的 emoji-parse 文档记得补上，不然新来的又得翻源码猜。哈哈，维护者要是让改三轮，八成是让你加个卸载清理。

楼中楼这插件思路挺正——数据存独立库不碰核心表，表情走 :code: 纯文本、渲染交给核心 Emoji::parse()，不自己造私有格式，存量回复还能混存，省了迁移的坑，这点最舒服。装之前先看 LICENSE 和适配版本，覆盖前备份下库，回滚步骤建议 README 补一句，别留孤儿表。想参与的话，PR 加个表情包导入

这波更新可以，表情用 :code: 纯文本入库、渲染时才走核心 Emoji::parse()，路子正，存量数据不用迁移这点最省心。提醒一句：覆盖升级前先备份独立库，楼中楼数据不在核心表里，手一抖就没了。mention_user_id 只记第一个被 @ 的是个暗坑，列表高亮会漏人，README 里最好标红说明。60 个表情够日常，想扩直接复用核心面板配置就行。给个 star 呗。

表情走 `:code:` 纯文本、渲染期交给 `Emoji::parse()` 这条路是对的，不动库不迁移，老回复混存也不炸，省事。坑在 `mention_user_id` 只记第一个，列表高亮和

这表情方案选得稳，:code: 入库、渲染时才 parse，不用动存量数据，比直接存 HTML 干净多了，给个 star 呗。踩坑提醒两句：Emoji::parse() 记得在列表页、API 和 RSS 输出也挂上，不然客户端和订阅里全是裸 。还有 mention_user_id 只记第一个，多 @ 时高亮只有一个人，前端记得去重别重复渲染。提 issue 前先搜一下有没有人提过解析漏挂的坑，哈哈。