audit_fenix counts only revives that landed: bag consumption and failed revives go uncounted, and custom boss drivers log no [death] lines

[mtklein]

Ombudsman S1 on the v0.18 qualification: audit_fenix reported 5 Fenix Downs across run 1's 53 logs; the bags' own fenix= counts dropped by 14. vector_crash used 8 on Zombied members that never raised (actor 1's Fenix Down on entity 2 never landed (841 ticks) -- forgetting it, fenix 24 -> 16; the Zombie handling itself is #190); train_done used 2 in the Ghost Train fight, whose bespoke driver logs no [death] lines so neither audit sees the deaths; fc_alcove used 4 where 3 were reported. Count Fenix consumption (bag deltas per fight and per care stop) alongside landed revives, flag failed revives, and give the custom set-piece drivers (Ghost Train and any other non-newFightDriver boss drivers) the [death] line the lib driver writes.

[mtklein]

Half of this is done on main (d332cb6): the audit now counts what left the bags beside what landed.

It reads the running counts the logs already print — the fenix=<n> field of a care or shop line, and the <n> left tail of a care use — and sums the drops inside an attempt as consumption, attributed to the same fight a landed use would be. A retry reloads its checkpoint and restores the bag, so each attempt starts its own baseline and a refill never reads as a negative spend. A Fenix the driver confirmed and then abandoned (never landed (841 ticks)) is now its own kind rather than dropped.

Over the current 72 route logs it reproduces the ombudsman's figures from the logs themselves:

Fenix audit: 1 flagged segment/kind(s) (>2 Fenix in a boss, or any in a random) across 72 logs, 5 landed, 14 left the bags, 8 confirmed and never landed.

segment                      attempt fenix  kind    why
fc_alcove                        1/3     3  RANDOM  Fenix in randoms -- underleveled or lab these encounters

spent without raising anyone (bag drop above landed revives):
  vector_crash: 8 left the bag, 0 landed -- 8 raised nobody (8 confirmed and never landed)
  train_done: 2 left the bag, 0 landed -- 2 raised nobody (no landing line accounts for them)

train_done's "no landing line accounts for them" is exactly this issue's other half: the Ghost Train's bespoke driver does not go through newFightDriver, so it writes neither the [death] line nor a landing line, and both audits are blind to that fight. That half is still open and is sequenced after the #218 work in gen_sabin_train.lua lands, to avoid two hands in the same file.

The vector_crash 8 are #190 (Zombie handling); fc_alcove is #221.

[mtklein]

Second half scoped, now that gen_sabin_train.lua is free (the #218 work merged in 47baeed).

The Ghost Train fight is driven by a bespoke driver rather than newFightDriver, so it writes neither the [death] line nor the Fenix landing line the lib driver writes. That is why train_done reads:

train_done: 2 left the bag, 0 landed -- 2 raised nobody (no landing line accounts for them)

Both audits are blind to that fight: audit_fenix cannot attribute the two Fenix Downs, and audit_boost cannot see the deaths that prompted them or what BP was banked when they happened. The bag delta is the only reason we know anything happened at all.

The fix is to give every bespoke set-piece driver the same two lines the lib driver emits — [death] f+N entity E char C from HP/MAX by slot S cmd $XX atk $YY ... bp=N party_bp=... and the Fenix landing/never-landed pair — rather than to rewrite those drivers onto newFightDriver. Ghost Train is the one this issue names; the sweep should find any other non-newFightDriver boss driver on the route and do the same.

Sequenced after the #219 route regeneration, since that will move these fights anyway and the new lines should be measured against the regenerated logs rather than the current ones.

[mtklein]

From the wt/field-lib work (#190): the battle side of the Zombie waste needs a guard in tools/tests/lib/ot6.lua -- raiseDecision should treat a member with status-1 $02 (Zombie) as not a Fenix Down target, since a revive on a zombie never lands (the v0.18 qualification burned 8 that way: build/attempts/v018-qual1.log:8551 actor 1's Fenix Down on entity 2 never landed (841 ticks) -- forgetting it). Zombone is on the Gate cave route (maps 384/385) and world groups 54/58/62, so the walked route can draw it again. ot6.lua is owned by wt/driver-status this wave; this lands in the ot6.lua queue right after it, alongside the field-side cure row (CARE_STATUS_CURES zombie -> Revivify) that wt/field-lib added.

[mtklein]

Fixed on main in 6092649 (wt/audit-fenix). Two counts side by side -- landed and left-the-bag -- with every never-landed Fenix named and the threshold on the larger; care stops attributed to the fight before them whatever their tag; [death] lines read; ninja logs split per edge. On the retained v0.18 log set: 5 -> '5 landed, 14 left the bags, 8 confirmed and never landed', with vector_crash's 8, fc_alcove's 4th and train_done's 2 each accounted for by name. Thirteen custom fight drivers now write battle-open and [death] lines (six previously invisible deaths surfaced at once). The battle-side fix the waste points at -- raiseDecision must not Fenix a zombie -- is tracked under #245 with the other fight-driver follow-ups. Evidence: build/attempts/wt/audit-fenix/.