弹幕字号按画面短边自动定，竖屏成片不再字大到铺满整行

1. 字号基准从「画面高度」改成「画面短边」
   以前合并时只用高度比换算字号（字号 × 视频高 ÷ 弹幕文件高）。横屏弹幕文件
   （1920x1080、60 号）配竖屏视频（720x1280）时会被放大到 71 号，而画面只有
   720 宽，一条 10 字弹幕就铺满整行。横竖屏互换时高度不是约束文字宽度的维度，
   短边才是：横屏取高、竖屏取宽。

2. 「弹幕字号」填 0 的含义从「跟随弹幕文件」改成「自动按画面分辨率」
   取画布短边的 5.56%（60/1080）。于是 1920x1080 → 60、1280x720 → 40、
   960x540 → 30，横屏行为与以前完全一致；720x1280 → 40（以前 60）、
   640x1280 → 36。填大于 0 仍是精确像素覆盖。

3. 录制端竖屏档位预设 720x1280 的字号从 60 改成 40
   原来横屏三档都是短边的 5.56%，只有竖屏这档是 8.33%，比横屏大 50%。
   改完四档口径一致，新录的弹幕文件和成片也对得上。

4. 坐标系和字号拆开
   unifyDanmuSpace 只负责把 PlayRes 统一到视频分辨率，字号统一交给
   applyFontSize 按最终画布算，避免两处各改一次。

5. .gitignore 加上 /avatar_cache
   头像缓存挪到程序目录后，程序正好跑在仓库里，缓存目录会被 git 看见，
   git add . 会把那 336 个 PNG 一起提交进去。

已验证：
- 新增 TestShortSide / TestAutoFontSize / TestSubConfigsMatchAutoFontSize /
  TestApplyFontSize；TestUnifyDanmuSpace 改成只校验 PlayRes，并且新增断言
  确认它不再动字号。
- 反向验证：把短边规则临时退回「按高度」，TestAutoFontSize 报
  「720x1280 应为 40，实际 71」「1080x1920 应为 60，实际 107」，
  TestApplyFontSize、TestSubConfigsMatchAutoFontSize 同步失败。
- 端到端：造 720x1280 竖屏视频 + 1920x1080/60 号的 jsonl，字号填 0 真跑一次合并，
  日志打出「竖屏画布 720x1280，弹幕字号自动取 40」；同一输入再用旧规则跑一次对照，
  抽同一时刻的帧量墨迹高度：改前 46px、改后 25px（1.84 倍）。
- gofmt / go vet / go build / GOOS=linux go build / go test 全过。

config.go

@@ -137,7 +137,7 @@ type configData struct {
 	MergeDelDanmu  bool   `json:"mergeDelDanmu"`  // 合并完成后删除弹幕文件
 	MergeOutputDir string `json:"mergeOutputDir"` // 合并完成后成片移动到该文件夹，留空不移动
 	MergeBitrate   int    `json:"mergeBitrate"`   // 合并成片的目标码率（Kbps），0 表示使用默认质量
-	DanmuFontSize  int    `json:"danmuFontSize"`  // 合并时弹幕文字的字号（头像随字号等比缩放），0 表示跟随弹幕文件
+	DanmuFontSize  int    `json:"danmuFontSize"`  // 合并时弹幕文字的字号（像素，头像随字号等比缩放），0 表示按画面分辨率自动
 
 	// 新添加主播的默认录制档位（留空/非法按第二高）与自定义时的码率上限
 	DefaultQualityPref string `json:"defaultQualityPref,omitempty"`
@@ -419,7 +419,7 @@ func checkConfig() {
 		os.Exit(1)
 	}
 	if config.DanmuFontSize < 0 {
-		lPrintErrf("%s里的danmuFontSize不能小于 0（0 表示跟随弹幕文件）", configFile)
+		lPrintErrf("%s里的danmuFontSize不能小于 0（0 表示按画面分辨率自动）", configFile)
 		os.Exit(1)
 	}
 	if config.DefaultBitrate < 0 {