Adds an additive `isExpanded: Binding<Bool>` initializer to
`ExpandableHeaderView` so callers whose expand/collapse preference must
survive view recreation (e.g., persisted across app launches in PR 6c)
can drive the view from caller-owned storage. The original
zero-ceremony `ExpandableHeaderView(title:count:content:)` initializer
is preserved unchanged, so Authenticator's existing `ItemListView` call
site compiles without modification.

Chose option (c) from the brief's "cleanest approach" guidance: dual
storage on a single type. The struct carries both an `@State private
var internalIsExpanded` (used when no binding is supplied) and an
`externalIsExpanded: Binding<Bool>?` (set by the binding init). A
computed `isExpanded: Binding<Bool>` resolves to whichever storage the
initializer populated. This:

- Avoids the brittle `State(initialValue:).projectedValue` assign-in-
  init trick, which loses SwiftUI's state-tracking cell.
- Avoids a public wrapper-view shim (approach a), which would expose
  additional API surface and leak an implementation type into call
  sites.
- Keeps `body` on a single `@Binding` read path.
- Preserves the `ExpandableHeaderView<Content>` identity for both
  initializers — no subtype or factory-function redirection needed.

Authenticator's call site in
`AuthenticatorShared/UI/Vault/ItemList/ItemList/ItemListView.swift:275`
remains unchanged and still resolves to the no-binding initializer.

Adds `ExpandableHeaderView+ViewInspectorTests.swift` covering:

- `test_init_withoutBinding_startsExpanded` — no-binding init renders
  child content on first render (expansion state defaults to true).
- `test_init_withBinding_reflectsBindingState` — binding init reads the
  initial value from the caller's binding (true ⇒ content visible,
  false ⇒ content hidden).
- `test_init_withBinding_updatesThroughBinding` — tapping the header
  writes the toggled value back through the caller-supplied binding.

All three tests pass against BitwardenKit on iPhone 17 / iOS 26.1.