refactor(web): unify per-type item field selection behind ItemDescriptor

[allisson]

Problem

The "which fields matter for type X" decision was re-encoded in four places:

• vault-list search switch (route.tsx, 44-line per-type switch)
• getItemSubtitle (ItemCard.tsx)
• read-only detail renderer ($itemId.tsx)
• form field registry (item-fields/index.ts)

Search + subtitle carried as string casts (item type unknown at the call site) and neither was directly tested.

Change

Deepen the form registry with a pure, React-free sibling — ITEM_DESCRIPTORS in item-fields/descriptors.ts:

• Each entry keyed by VaultItem['type'], typed against Extract<VaultItem, {type: K}> → no casts inside entries.
• Two dispatchers getItemSearchText / getItemSubtitle carry the one contained assertion and return '' for unknown types (preserves the old default safety).
• Kept separate from index.ts so the hot list-filter path does not pull the field-editor component graph into its bundle.
• getItemSubtitle re-exported from ItemCard.tsx → existing import paths + the trash test mock keep working (zero caller churn).

route.tsx swaps its 44-line switch for item.title... || getItemSearchText(item)....

Invariant (locked by test)

The search haystack is a plaintext index — toSearchText emits no secret material (password, number, cvv, secret, clientSecret, privateKey, passphrase, mnemonic) and excludes the generic title. A table-driven test asserts this across all 7 types + developer_credential×3 modes + crypto_wallet×2 + an unknown type.

Scope

Detail renderer (ReadComponent) and TypeFilter TYPE_OPTIONS are deliberately left as the obvious next descriptor fields (noted in CONTEXT.md).

Verification

• descriptors.test.ts — 31/31 pass
• web suite — 187/187 pass (trash mock resolves via re-export)
• tsc -b clean · eslint clean

Net −76 / +15 in touched source; previously-untested search + subtitle logic now sits behind one tested interface.

🤖 Generated with Claude Code