docs(vt): KB 05 second citation pass — 31 requirement types, f0.c categories and dz.o.h readers resolved

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/research/vtank-kb/05-looting-and-utl.md

@@ -720,19 +720,19 @@ independently re-implements §1's exact grammar: header/version detection
 (`VtankLootProfileSerializer.cs:92-107`), the length-prefixed v1 payload
 format and the fixed-line-count v0 legacy table
 (`LegacyPayloadLineCount`, `VtankLootProfileSerializer.cs:376-388` —
-independently verified in this pass against every one of VTClassic's 30
+independently verified in this pass against every one of VTClassic's 31
 `Read()` methods, §1.3/§1.2; every bucket matches exactly), the
 `SalvageCombine` extra block including its optional trailing value-mode
 section, and preserves any unrecognized block/requirement type verbatim
 (`VtankLootExtraBlock`/`cUnsupportedRequirement`-equivalent
 `VtankLootRequirement.Payload`, `VtankLootProfileSerializer.cs:11-15`).
-Round-trip fidelity for every one of the 30 known requirement types plus
+Round-trip fidelity for every one of the 31 known requirement types plus
 unknown-block preservation is exercised by
 `tests/AcDream.Plugins.MossTank.Tests/VtankLootProfileSerializerTests.cs`
 (all four tests read).
 `VtankLootRequirementEvaluator.IsMatch`
 (`src/AcDream.Plugins.MossTank/VtankLootRequirementEvaluator.cs:110-190`)
-implements the **entire** 30-entry requirement vocabulary (verified
+implements the **entire** 31-entry requirement vocabulary (verified
 switch-arm-by-switch-arm against §1.3's table, including the deliberately
 dead `DamagePercentGE` always-`false` and the `DisabledRule`
 never-matches-when-enabled semantics) plus every `ComputedItemInfo` formula
@@ -792,23 +792,27 @@ constants).
   (`a10.j = A_0.Value<int>("shareLoot") != 0;`, alongside `name`/`level`/
   `maxHealth`, `id.cs:212-221`; field declared at `id.cs:30`). MossTank's
   `member.ShareLoot` mapping (`Looting.cs:1224`) is confirmed correct.
-- **`f0.c` enum members `a` and `d`** (`f0.cs:11-17`) — only `b`
-  (item-needs-ID) and `c` (corpse-needs-ID) were observed at call sites in
-  this pass; the other two members' purposes are unknown.
+- **`f0.c` enum members — RESOLVED** (citation pass 2026-09-06): `f0.c` is the
+  ID-request category. `a` = the "Set default profile" inventory-scan sweep
+  (`da.cs:577,581-583,594-599`), `b` = corpse-item ID (`hv.cs:260,293,306`),
+  `c` = corpse ID (`fo.cs:177`), `d` = door ID for the `OpenDoors` rule,
+  range-gated by `DoorIDRange` (`b7.cs:99-104`).
 - **The full write/reset surface of `dz.o.s`/`dz.o.t`/`dz.o.c` and similar
   single-letter bookkeeping fields** on the large (~1900+ line) `ga`/`s.o`
   class, which covers combat, nav, and loot state together — only the
   specific call sites this doc cites were confirmed; there may be
   additional gating logic on these flags elsewhere in `ga.cs` not surfaced
   here.
-- **Whether anything actually consumes `dz.o.h`** (the table `Keep`/
-  `Sell`/`KeepUpTo`/`User1`-`5` decisions land in uniformly after pickup,
-  §3.7) as a real vendor-sell queue, versus it being purely a bookkeeping/
-  report table — no rule class reading it back out was found among the
-  ~35 rule classes `cLogic.cs` registers (only the loot-relevant ones were
-  opened in this pass). This makes a direct sell-path comparison against
-  MossTank's explicit `_sellPendingItem`/`ContinueSell` staging
-  (`Looting.cs`) inconclusive rather than a confirmed match or gap.
+- **`dz.o.h` consumers — RESOLVED** (citation pass 2026-09-06): no internal
+  rule reads it. Its only readers are two external-plugin API surfaces gated
+  on `eExternalsPermissionLevel.FullUnderlying` — `GetByAction(eLootAction)`
+  (`uTank2/PluginCore.cs:274-278` → `PluginCore.a(eLootAction)` at
+  `:2752-2776`, which also prunes ids no longer in inventory) and
+  `GetCustomLootActionItems(eLootAction)` (`uTank2/PluginCore.cs:466-478`).
+  Writes: `hv.cs:184` (add), `hv.cs:73-75` (remove on release). It is a
+  bookkeeping + third-party query table, NOT a vendor-sell queue, so
+  MossTank's explicit `_sellPendingItem`/`ContinueSell` staging is a
+  confirmed MossTank-side addition with no VTank counterpart.
 - **The exact semantic of network message type `63408`, event `34`** —
   treated here as "corpse closed/emptied" by contextual inference (it
   resets the same state as event 82 / a failed event-406), not