Master tables: extend accounts/ with account_type, no parallel collections

Superseded by 2026-07-11-user-identity-entry-model — the typed-discriminator primitive is retained but the collection is renamed identities/, the type list widens to ~31 variants across 12 buckets, and self becomes a reserved singleton row (replacing inline PAN on users/{uid}).

Decision

Extend the existing users/{uid}/accounts/{accountId} record with a typed account_type discriminator and per-type optional fields. Do not create parallel collections (bank_accounts, demat_accounts, mf_folios, etc.).

Why

users/{uid}/accounts/{accountId} already exists as the unit-of-share + document anchor. Creating six parallel collections (bank_accounts, demat_accounts, mf_folios, loans, properties, employers) would violate the no-second-style rule and duplicate the share-scoping logic. A typed discriminator on the existing record is the right primitive.

Impact

• account.ts gains account_type (savings / current / credit_card / loan_home / loan_car / loan_personal / loan_education / loan_ev / fd / demat / mf_folio / employer / property_residential / property_commercial / property_land / other) and per-type optional fields (IFSC, masked account number, broker slug, client ID, AMC slug, folio number, loan account number, TAN, property address).
• Master-entity linking pipeline matches extracted identity fields against this typed account record.
• Documents continue to reference accounts via DocumentRecord.account_id.
• Affects inbox-document-types, pillar-inbox, pillar-portfolio, pillar-expense.

Status

Superseded by 2026-07-11-user-identity-entry-model.

Sources

• .context/wiki/decisions/* § "2026-05-31 — Master tables: extend accounts/ with account_type, no parallel collections"