fix: miscalculate item original TP on Tank Transportation

[HetmesAskalana]

目前的版本因为没有收集master数据，导致在战车运输中漏算了原始装备TP（type不存在所以取到了0），最后显示值仅包含战车增益。

[HetmesAskalana]

现在的TP算出来好像还会算多一点点，烦请老师先等下我晚点再去开一把看看检查一下。
现在手头有点事

[KagamiChan]

感谢修复，这个 PR 对 regression 的判断和计算结果本身看起来是成立的：member item 只有 api_slotitem_id 时，通过 master 的 api_type[2] 可以补回基础 TP（例如 R35 的战车 TP 从仅 bonus 18 恢复到 8 * 0.75 + 18 = 24）。有两个实现层面的建议：

1. master data 或许更适合在 adapter 层合并

目前 PR 把 itemMasters 从 BattleViewArea -> transportPoints -> getTPDazzyDing -> itemTP 一层层传下去。不过 selectFleetsEquips 返回的 ProphetEquipEntry 本身已经是 [memberItem, masterItem, level]，而 transformToLibBattleClass / transformToDazzyDingClass 构造 raw.poi_slot 时只保留了 e[0]，把已经拿到的 e[1] master 丢掉了。

能否考虑在这个 adapter 边界把二者规范化一次，例如：

const [member, master] = equip ?? []
return member ? { ...master, ...member } : null

这里 member 放在后面，避免 master 的 api_id 覆盖装备实例 ID。这样 raw.poi_slot 也会真正符合当前的 ApiSlotItemLike（member 字段 + api_name / api_type），下游 TP 计算可以继续只依赖 fleet/ship 数据，不需要新增整张 ItemMasterMap 以及多层参数传递。类型上也可以直接复用现有的 APIMstSlotitem / ProphetEquipEntry，避免新的 ItemMasterLike 和 assertion。

2. 测试中建议明确区分 member item 与 enriched item

把最后一个测试里的 slotItem(75) 改成 { api_slotitem_id: 75 } 是有必要的：原来的 slotItem() 会自带 api_type，导致测试绕过 master fallback，即使 wiring 没修好也可能通过。不过直接改成匿名对象后，这个意图不太容易看出来。

建议增加一个类似的 helper：

const memberItem = (slotitemId: number) => ({ api_slotitem_id: slotitemId })

并考虑把现有 slotItem() 改名为 itemWithMasterData() / enrichedSlotItem()。这样 fixture 的两种数据形态会更明确。如果采用 adapter 方案，也可以把关键 regression test 放到 adapter 测试中，直接验证 [member, master] 转换后的 raw.poi_slot 含有正确的 api_type。

相关的 17 个 transport/view-model 测试和 lint 在 PR head 上都通过了。

[KagamiChan]

再补充一个仅针对 TP 计算公式结构的建议。

这个 PR 对 regression 的修复是必要的，但在 fe75afc 之后，完整公式被分散到了 itemTP、shipTypeTP、shipBonuses、collect 以及多个 mode 判断中。继续沿用这个结构，未来调整规则时可能会越来越难以确认各部分之间的关系。

我建议后续将它重构为一条明确的计算公式：

base =
  Σ 舰种基础值
  + Σ 装备类别基础值

TP =
  floor(
    base × 规则倍率
    + Σ 特定装备追加值
    + 舰队级追加值
  )

计算模块可以只接受已经规范化的输入：

interface TransportItem {
  itemId: number
  category: number
}

interface TransportShip {
  shipId: number
  shipType: number
  eligible: boolean
  items: readonly TransportItem[]
}

普通运输和 Landing Operation 之间的差异则作为模块内部的规则数据，而不是分散在多个 helper 的条件分支里：

interface TransportRule {
  baseMultiplier: {
    numerator: number
    denominator: number
  }
  itemBonusById: Readonly<Record<number, number>>
}

唯一的 score(ships, rule) 可以按公式顺序完成：

1. 累加舰种和装备类别的基础值；
2. 应用规则倍率；
3. 加上特定装备的追加值；
4. 加上每支舰队最多一次的鬼怒改二 bonus；
5. 最后统一向下取整。

倍率可以用 3 / 4 这样的分数表示，避免在累计过程中引入浮点误差：

Math.floor(
  (base * numerator + (itemBonus + fleetBonus) * denominator) /
    denominator
)

planned 和 deliverable 也可以复用同一个计算函数：

{
  planned: score(ships, rule),
  deliverable: score(
    ships.filter(ship => ship.eligible),
    rule,
  ),
}

这也能消除当前 shipBonuses() 的顺序依赖：鬼怒 bonus 应根据本次参与计算的舰队整体判断，而不是先分配给数组中的第一艘鬼怒，再过滤无法参与运输的舰船。

迁移期间，getTransportPoint() 和 getTPDazzyDing() 可以暂时保留为输入转换层，但二者最终都应调用同一个计算入口，不再分别包含业务逻辑。调用方完成迁移后，再删除这些重复 helper 及其面向实现细节的测试。

这样 TP 的实现结构能够直接对应资料中的计算公式，同时也能把 member/master 数据的整理与业务计算本身分开。

[HetmesAskalana]

我可以先把 master data 的部分给整了，先解决漏算的核心问题
联合舰队应该是分开取整再相加的，现在可能是因为相加再取整造成了进位导致部分情况下多一点 TP
公式这块我看修改面可能有些大，这周可能没那么多精力去做活动也快结束了

[KagamiChan]

/ai-review

[petit-chiba]

Fixes tank-transport TP by merging member+master slot-item data into poi_slot/poi_slot_ex in the two battle adapters (so item api_type[2] supplies base TP instead of 0) and switches combined-fleet TP to floor main and escort fleets separately before summing, removing the sum-then-floor carry that over-counted tank TP. Per-fleet floor math and all new test expectations verified against the tables; 45 tests, tsc, and eslint pass. Only concern: the master-merge itself is untested and the new view-model regression tests bypass it, leaving the core fix unguarded.

[petit-chiba]

The fix's core — mergeEquipSlot giving member items api_type/api_name from master so base TP stops being 0 — is never exercised by any test: the new regression tests fabricate the merged shape by hand (battle-view-model.test.ts:56 and :81 put api_type directly into poi_slot) and getTransportPointFromFleets (transport.ts:216) has no master fallback, unlike getTransportPoint. A removed, mis-ordered, or master-undefined merge therefore silently reverts equipment base TP to 0 while the whole suite stays green — exactly the regression this PR claims to fix. Add an adapter-level test asserting transformToLibBattleClass/transformToDazzyDingClass emit api_type into poi_slot/poi_slot_ex (as the maintainer's review comment suggested), or fall back to the $equips store inside getTransportPointFromFleets.

[KagamiChan]

我可以先把 master data 的部分给整了，先解决漏算的核心问题 联合舰队应该是分开取整再相加的，现在可能是因为相加再取整造成了进位导致部分情况下多一点 TP 公式这块我看修改面可能有些大，这周可能没那么多精力去做活动也快结束了

好的，现在是已经可以开始看了的状态了吗，我这边觉得可以了，如果你已经改完的话，我们就 check in

[HetmesAskalana]

我可以先把 master data 的部分给整了，先解决漏算的核心问题 联合舰队应该是分开取整再相加的，现在可能是因为相加再取整造成了进位导致部分情况下多一点 TP 公式这块我看修改面可能有些大，这周可能没那么多精力去做活动也快结束了

好的，现在是已经可以开始看了的状态了吗，我这边觉得可以了，如果你已经改完的话，我们就 check in

关于这个BUG的修复我这边看应该已经可以了，后续的那个公式结构的问题以后有机会再做。

[KagamiChan]

好的，非常感谢，那我先合并了

[HetmesAskalana]

好的，感谢，辛苦您了