[PM-32009] feat: Integrate new cipher types into vault listing and search

[SaintPatrck]

🎟️ Tracking

PM-32009

📔 Objective

Third of three stacked PRs. Wires the Bank Account, Driver's License, and Passport types built in #6829 into the vault listing, search, and new item-type selection flow. After this PR merges (and the pm-32009-new-item-types flag is enabled), users can discover, filter, and create the new cipher types end-to-end.

Why it looks the way it does

• Item-type selection becomes a screen, not a dialog, when the flag is on. Six choices (Login, Card, Identity, Secure Note, plus the three new types) no longer fit a bottom-sheet affordance without crowding, and a dedicated screen gives the new types room for iconography and descriptions. The dialog path is preserved unchanged for flag-off users.
• SDK filter predicates currently return false for the new types. The SDK's CipherListViewType does not yet expose variants for these ciphers, and returning false is a safer default than a speculative mapping that might mis-categorize items once the SDK lands. Tracked under PM-34060, PM-32691, and PM-32694.
• "Note" renamed to "Secure note" in empty-state strings so the empty states read consistently alongside the new types in the selection screen.
• Feature-flag gating is applied at the data-extension layer rather than individual call sites so the zero-group-counts behavior is uniform across the vault surface and can be removed in a single step when the flag is retired.

Stacked on: #6829
Follow-up: SDK mapping work tracked under PM-34060 / PM-32691 / PM-32694

📸 Screenshots

To be added before marking ready for review.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the third of three stacked PRs integrating Bank Account, Driver's License, and Passport cipher types into the vault listing, search, and new-item-type selection flow. The change is feature-flag gated behind FlagKey.NewItemTypes, introduces a dedicated ItemTypeSelectionScreen when the flag is on (preserving the dialog path for flag-off users), and adds new VaultItemListingType, SearchType, and SearchableItemType variants plumbed consistently through navigation, ViewModel, and state. SDK filter gaps are explicitly returned as false with TODOs tagged to tracking tickets (PM-34060, PM-32691, PM-32694), and the "Note" → "Secure note" empty-state renaming is noted in the PR description.

Code Review Details

No findings at or above the posting confidence threshold.

Notes on intentional design that were reviewed and validated:

• CipherListView.filterBySearchType and CipherListView.determineListingPredicate return false for the three new types. This is a safer default than a speculative mapping and is documented with tracking tickets.
• bankAccountItemsCount, driversLicenseItemsCount, and passportItemsCount are hardcoded to 0 pending the same SDK work; behavior is acceptable given the feature flag gating.
• ItemTypeSelectionViewModel reads FlagKey.NewItemTypes and PolicyTypeJson.RESTRICT_ITEM_TYPES once at construction (non-reactive). This matches the pattern used in similar short-lived selection ViewModels.
• no_notes / new_note string resources were updated from "note" to "secure note", which also affects the Add flow title via VaultAddEditViewModel. This is called out as intentional in the PR description.
• Previous review feedback (SSH key exclusion comment, PolicyManager injection for Card filtering, style fixes) has been addressed in the latest commit.

[github-actions]

Checkmarx One – Scan Summary & Details – cda12be8-8fbe-4895-8fd2-d4d4a98c18d0

Great job! No new security vulnerabilities introduced in this pull request