ApiBridge: 调研并扩展钓鱼事件的钓场、咬钩强度与鱼获信息

## 背景

`xiv-companion` 已开始消费 ApiBridge 的 `fishing.cast.started` 和 `fishing.bite` 事件，用于记录出杆至咬钩的时间。目前协议只能可靠提供钓鱼状态变化和 `territoryId`，不足以支持以下后续功能：

- 自动识别玩家当前所在钓场，而不只是 Territory；
- 记录咬钩强度（弱、强、传说级等游戏实际可区分的类别）；
- 将一次咬钩、提钩结果和最终获得的鱼关联起来；
- 记录鱼的 Item ID、HQ、数量等稳定标识。

当前实现位于 `plugins/ApiBridge/ApiBridge/FishingEventSource.cs`。`fishing.bite` 目前只包含 `territoryId`，协议文档也明确说明不包含咬钩强度、鱼种或最终是否钓起。

## 目标

先完成可行性分析和数据来源验证，再设计向后兼容的协议扩展。重点是确保事件来自游戏已确认的状态或结果，避免通过动画时间、背包差分或本地化聊天文本进行脆弱推断。

## 待调研事项

### 当前钓场

- `FishingEventHandler` 或相关 EventFramework 数据中是否存在稳定的当前钓场/钓点标识？
- 如果只能获得 `territoryId` 和玩家坐标，是否可以基于 `FishingSpot`/相关 EXD 数据可靠匹配 `FishingSpot.RowId`？
- 同区域重叠钓场、洞穴/楼层、海钓和叉鱼是否存在歧义？
- 钓场应在出杆时快照，还是在进入钓鱼状态/位置变化时单独发布？

### 咬钩强度

- 客户端结构、钓鱼事件参数、网络包或 UI 状态中是否有稳定的咬钩强度字段？
- 该字段是否在进入 `FishingState.Bite` 的同一帧可用，生命周期有多长？
- 游戏实际类别及其稳定枚举值是什么？未知值应如何透传？
- 普通钓鱼、以小钓大、海钓和特殊任务是否使用相同语义？

### 鱼获结果

- 是否存在比背包变化或聊天日志更可靠的“钓鱼成功”结果来源？
- 能否取得基础 Item Row ID、数量、HQ、收藏品等信息？
- 如何区分脱钩、主动收杆、取消、鱼跑掉和成功获得物品？
- 如何将结果与对应的 cast/bite 关联；是否需要由插件生成 `castId`？
- 以小钓大时，前一条鱼作为下一次出杆输入应如何表达？

## 协议设计候选

以下结构仅用于指导调研，不应在确认数据来源前视为最终协议：

```json
{
"event": "fishing.bite",
"data": {
"castId": 42,
"territoryId": 129,
"fishingSpotId": 17,
"strength": "strong"
}
}
```

```json
{
"event": "fishing.catch",
"data": {
"castId": 42,
"territoryId": 129,
"fishingSpotId": 17,
"itemId": 12345,
"quantity": 1,
"hq": false
}
}
```

也需要评估是否增加 `fishing.cast.ended`，以表达 `caught`、`escaped`、`cancelled` 等结果，或由 `fishing.catch` 与现有状态变化共同表达。

## 兼容性要求

- 保留现有 `fishing.cast.started`、`fishing.bite` 和 `fishing.state.changed` 的既有语义；新增字段应为向后兼容扩展。
- 未知枚举值不得导致客户端解析失败。
- Item 使用基础 Lumina Item Row ID，不使用本地化名称作为标识。
- 若钓场或强度无法可靠取得，应使用显式 `null`/省略策略或暂缓字段，而不是猜测。
- 协议变更需要同步更新 `plugins/ApiBridge/docs/protocol.md` 和代表性测试。
- 不在事件中加入角色名或其他无关隐私数据。

## 建议的完成标准

- [ ] 验证钓场、咬钩强度、鱼获结果各自可用的数据来源和生命周期；
- [ ] 给出普通钓鱼、以小钓大、失败/取消流程的实际状态序列；
- [ ] 明确哪些字段可靠、哪些字段只能作为 best-effort；
- [ ] 确定事件关联方案（例如 `castId`）和最终 JSON schema；
- [ ] 更新协议文档与测试计划；
- [ ] 将具体实现拆分为后续 issue，或在本 issue 中确认实现范围。

## 消费端预期

`xiv-companion` 计划用这些事件展示当前地图/钓场、咬钩强度、鱼获名称，并把最近多次出杆、咬钩和鱼获记录关联到同一条时间轴。消费端可以自行使用游戏数据把 Item ID 和 FishingSpot ID 映射为本地化名称。

Start by reading plugins/ApiBridge/ApiBridge/FishingEventSource.cs and plugins/ApiBridge/docs/protocol.md, then trace the existing fishing events and their available data sources. Document reliable lifecycles and state sequences for fishing spots, bite strength, and catch results, define the compatibility and correlation scheme, and finish by updating the protocol documentation and representative test plan or splitting implementation work into follow-up issues.

Written by the indexing model from the issue text.