Rebuild the feed bottom bar on standard SwiftUI controls

[bradleymackey]

Replaces the hand-built chrome at the bottom of the vault feed with
standard controls.

The problem

VaultItemFeedView.unifiedInfoSection was a hand-assembled bar:
.background(Color.primary.opacity(0.05)) + RoundedRectangle(12)
wrapping two buttons that were styled entirely by hand — .padding(8/16)

• .background(...) + .clipShape(Capsule()) + a forced
  .foregroundStyle(.white). Neither had a pressed state.

The Clear button used .background(Color.secondary). Color.secondary
is a label colour, not a fill; in dark mode that is a light grey behind
white text.

The tag filters were TagPillView + .onTapGesture, which produces no
.isButton trait, no VoiceOver activation, no keyboard or Switch Control
focus, and no press feedback. At .footnote with 8pt vertical padding
the tap target was roughly 29pt tall.

What changed

Element	Before	After
Tag filters	TagPillView + .onTapGesture	Toggle + .toggleStyle(.button) + .buttonStyle(.bordered) + .buttonBorderShape(.capsule) + .tint(tag colour)
Clear	hand-built capsule	.buttonStyle(.bordered) + .buttonBorderShape(.capsule)
Edit/Done	hand-built capsule	.buttonStyle(.borderedProminent) + .buttonBorderShape(.capsule)
Bar container	Color.primary.opacity(0.05) + RoundedRectangle(12)	removed; the controls sit on the content the way a system bottom bar does
Animation	four stacked .spring(response: 0.3, dampingFraction: 1.0)	.snappy
Status label	.foregroundColor(.secondary) repeated on seven sibling views	one .foregroundStyle(.secondary) on the container

Selected and unselected tag states now come from the toggle style rather
than the brightness-derived fill and stroke colours, so the pills pick up
the standard tinted/untinted treatment. TagPillView itself is unchanged
and still used by the three read-only sites that display an item's tags.

VaultListView's add-item menu label becomes
Label("Add Item", systemImage: "plus") instead of a bare Image.

Reordering still uses .draggable/.dropDestination and
VaultItemFeedReorderer. The LazyVGrid is deliberate, and List.onMove
would force a single-column layout.

Why this is not a .toolbar

The obvious native move is to put this in .toolbar — item count in
ToolbarItem(placement: .status), EditButton() and Clear in
.bottomBar — and let iOS 26 render the bar on Liquid Glass.

That was tried and reverted. Toolbar content does not rasterise reliably
in the snapshot harness: the bar drew twice (once over the navigation
title, once at the bottom), the conditional Clear button never appeared
even with two tags active, and EditButton() still read "Edit" in a
snapshot where the cards had already rendered their editing state — so
the \.editMode binding had not been applied at capture time.

This is the same class of problem as the Liquid Glass finding in the
previous commit: UIKit-hosted chrome does not resolve when the hierarchy
is rendered off-screen. Moving this chrome into a toolbar would therefore
have silently gutted the six unifiedBar_* tests that exist to cover it.

The bar stays in .safeAreaInset, which rasterises correctly, and the
standardization is achieved through the control styles instead.

Verification

Local, iPhone 18 Pro Max / iOS 27.0:

• xcodebuild build-for-testing — TEST BUILD SUCCEEDED
• Full suite, -parallel-testing-enabled NO — TEST EXECUTE SUCCEEDED,
  2834 passed, 0 failures across 24 bundles, matching the pre-change count
• 15 snapshots re-recorded and visually reviewed: 13 feed, plus
  VaultMainNavigationView and VaultAutofillCodeSelectorView, which
  both embed the feed
• make format + make lint — clean

⚠️ Automatic CI is still disabled (#548), so this is local verification only.

🤖 Generated with Claude Code