合并前重排弹道并支持自定义弹幕字号

用户反馈两件事：弹幕想再小些；某场合并的 1:19:25 处弹幕糊在一起（把成片抽帧
出来一看，是同一弹道上两条弹幕追尾叠字）。

重叠的根因：弹幕从上游原版的 .ass 还原成 jsonl 时，lane 是按「只有内容」的
宽度反推的（原格式的 x/y 就是这么摆的），而渲染用的是「昵称(uid)：内容 + 头像」
的完整宽度 —— 后者占位时间长得多，照搬原弹道必然追尾。用用户那份 3011 条的真实
jsonl 验过：按渲染公式统计，重排前 960 条（31.9%）追尾，重排后 0 条。

- 新增 relayoutLanes：渲染前按最终字号统一重排弹道并重算宽度，公式和录制时的
  placeLane 完全一致，所以录制下来的 jsonl 重排后弹道不变（已加用例覆盖）。
- 空弹道用 math.MinInt64 占位：placeLane 的条件是「本条出现时间晚于上一条的让位
  时刻」，零值下 0 > 0 不成立，第一条弹幕（还原出来的时间可能正好是 0）会占不上
  弹道、占用状态丢失，后面又跟着乱排。录制的弹幕时间总大于 0，所以原逻辑没暴露。
- 弹道全满（100 条都占着）时退到最早让出来的那条：录制时是直接不写这条，合并时
  丢一条等于凭空少一句弹幕，压一点也比丢了强。
- 新增 danmuFontSize 设置（合并分区，0 = 跟随弹幕文件）：覆盖渲染字号，头像按
  同一比例缩放；改了字号会在重排时一并生效，不会因为宽度变了又追尾。

验证：layout_test.go 5 个用例；用新 ffmpeg（用户已自行升级到 n9.0.2）在隔离实例上
跑了真合并 —— 字号 95 以上的对照（60px → 42px：抽帧量到的弹幕墨迹高度 48px → 36px）、
按 1:19:00 裁出的 130 秒片段合并前后追尾 25 条 → 0 条；重跑 verify_settings.py
（新增第 8 节覆盖字号字段）、verify_pick.py、verify_streamer_br.py 无回归；
go test ./...、gofmt、go vet 干净。

README.md

@@ -81,6 +81,7 @@ GOOS=windows GOARCH=amd64 go build -o acfunlive.exe
     "mergeDelDanmu": false,     // 合并完成后删除弹幕文件（ass、nick.ass、jsonl）
     "mergeOutputDir": "",       // 合并完成后成片移动到该文件夹，留空则不移动
     "mergeBitrate": 0,          // 合并成片的目标码率（Kbps），0 表示使用默认质量
+    "danmuFontSize": 0,         // 合并时弹幕文字的字号（像素），0 表示跟随弹幕文件；头像随字号等比缩放
     "defaultBitrate": 0,        // 新添加主播的默认 bitrate，0 表示码率最高的直播源
 
     "webExternal": false,       // 是否允许外网访问 web UI，false 时只监听本机 127.0.0.1
@@ -213,6 +214,8 @@ acfunlive -danmuburn xxx.jsonl -video xxx.flv -ffmpeg D:\tools\ffmpeg.exe
 
 手动停止录制（web UI 的`停止`按钮或命令行里停止）不会触发自动合并，重新开始录制后新的一组文件仍会在直播结束时自动合并。这一场想补出成片的话，用下面的`手动合并`。合并需要 ffmpeg，且会占用 CPU 或显卡资源，长录播的合并耗时较长。
 
+弹幕字号默认沿用弹幕文件里记的字号（1080p 下通常是 48~60），嫌大可以调`弹幕字号`，头像会跟着等比缩小。合并前会按最终字号把弹幕重新排一遍弹道：从上游原版的`.ass`还原出来的弹幕，原本是按「只有内容」的宽度占位的，而渲染用的是「昵称(uid)：内容 + 头像」的宽度，占位更久，照搬原弹道会追尾叠字——重排按完整宽度重新分配，同一条弹道上不会再有两条弹幕叠在一起。
+
 停止录播时会向 ffmpeg 发送正常退出的指令，让它把文件正常收尾（直接杀进程会在文件尾部留下损坏的数据包，mp4 甚至会因为缺少 moov atom 而整个读不出来）。
 
 `autoMerge`、`mergeDelVideo`、`mergeDelDanmu`三项互不影响，可以同时开启：第一项决定是否自动合并，后两项是合并成功后的清理动作。