feat(apple): saved devices and targeted transfers UI

Adds the native SwiftUI Saved Devices experience on top of the production
saved-device core, as a top-level destination in the iOS tab bar and the
macOS sidebar.

Core seam:
- App-facing saved-device domain models mirroring core/SavedDeviceModels.kt,
  with lifecycle helpers (canReceive/canResume/canCancel/canDelete) so views
  never hand-roll state checks.
- 21 gateway methods through CoreGateway/CoreRepository with UniFFI mapping.
  cancelTargetedTransfer, forgetSavedDevice and blockDevice run off the serial
  lane: each must reach the core while a targeted receive is blocking it.
- Payload-free pairingChanged/targetedTransferChanged signals, dispatched
  before the numeric-transferId guard since saved-device events identify
  their subject by peer endpoint or a string transfer id.

Experience:
- Screen lists saved devices and outstanding consent requests only; the
  global targeted-transfer history stays out, reachable per device.
- Details as a sheet with detents on compact layouts and a native inspector
  on macOS, owning Send, label, forget/block and that device's transfers.
- Label editing is transactional: the draft and editor survive a failed
  write, conflicting actions are refused while saving, and the editor closes
  only after the core confirms.
- Pairing and targeted-offer consent hosted at the app root, answerable from
  any tab and suppressed while a transfer approval is up. Dismissing a
  pairing prompt suppresses locally without consuming the single-use
  eligibility; dismissing an offer declines it, since an unanswered offer
  holds a slot in the core's bounded per-sender queue.
- Targeted send reuses the invitation composer's affordances with file,
  folder, rename, replace and cleanup parity. Picker copies are released on
  replace/remove/clear/cancel and after a successful create, but kept after a
  failure so retry does not require re-picking.
- Notifications for pairing requests and offers (withdrawn once answered) and
  for terminal targeted transfers. Wording follows direction: on the sending
  device the peer finished receiving, not us.

Localization:
- Widens 52 saved-device keys from kmp-only to both platforms.
- Five keys carried a literal %1$s with no declared args, which Compose
  renders positionally but the Apple generator emits as a plain constant,
  leaking the placeholder into the UI. They now use named args; Compose
  output is byte-identical.
- Adds targeted_offer_title/body. Reusing the invitation approval copy stated
  the roles backwards, announcing the sender as the receiver.

Also surfaces core startup failures: the startup overlay is drawn above the
snackbar host, so a failed initialize() was indistinguishable from an app
that never finished loading. AppModel now keeps the reason, logs it, and the
overlay shows it with a retry, plus the technical detail in DEBUG builds.

Send and receive between two devices is verified only partially; a missing
endpoint-identity credential currently blocks startup on the test device.

apple/VniDrop/Features/SavedDevices/SavedDeviceExperienceModels.swift

@@ -0,0 +1,79 @@
+import Foundation
+
+/// Presentation-level saved-device models, ported from
+/// `feature/saveddevices/SavedDeviceExperienceModels.kt`.
+
+/// The one consent question currently worth asking. Only one is shown at a time:
+/// an incoming request always outranks an eligibility we could act on ourselves.
+enum PairingPrompt: Equatable, Identifiable {
+	/// We completed a qualifying transfer and may ask this peer to pair.
+	case eligibility(peerEndpointId: String, remoteDisplayName: String?)
+	/// This peer asked us; we approve or decline.
+	case incomingRequest(peerEndpointId: String, remoteDisplayName: String?)
+
+	var peerEndpointId: String {
+		switch self {
+		case .eligibility(let id, _), .incomingRequest(let id, _): return id
+		}
+	}
+
+	var remoteDisplayName: String? {
+		switch self {
+		case .eligibility(_, let name), .incomingRequest(_, let name): return name
+		}
+	}
+
+	var id: String {
+		switch self {
+		case .eligibility(let id, _): return "eligibility-\(id)"
+		case .incomingRequest(let id, _): return "incoming-\(id)"
+		}
+	}
+}
+
+struct PairingPromptState: Equatable {
+	var prompt: PairingPrompt?
+	var busy = false
+}
+
+struct TargetedOfferState: Equatable {
+	var pending: [PendingTargetedOfferModel] = []
+	/// Display names for senders we already have saved. A sender we have not
+	/// saved has no trustworthy name, so the UI falls back to a generic label
+	/// rather than rendering a peer-supplied string as if it were verified.
+	var senderDisplayNames: [String: String] = [:]
+	var respondingIds: Set<String> = []
+
+	var current: PendingTargetedOfferModel? { pending.first }
+
+	var currentSenderDisplayName: String? {
+		guard let current else { return nil }
+		return senderDisplayNames[current.senderEndpointId]
+	}
+}
+
+enum SavedDeviceTransferDirection: Equatable, Sendable {
+	case outgoing
+	case incoming
+}
+
+/// One targeted transfer as the details surface renders it: resolved against the
+/// local endpoint so "peer" means the *other* device, whichever side we are on.
+struct SavedDeviceTransferItem: Equatable, Identifiable, Sendable {
+	let id: String
+	let peerEndpointId: String
+	let peerDisplayName: String?
+	let direction: SavedDeviceTransferDirection
+	let transferName: String
+	let fileCount: UInt64
+	let totalSize: UInt64
+	let verifiedBytes: UInt64
+	let state: TargetedTransferStateModel
+	let createdAt: Int64
+	let updatedAt: Int64
+
+	var progressFraction: Double? {
+		guard totalSize > 0, state.isActive || state == .interrupted else { return nil }
+		return min(1, Double(verifiedBytes) / Double(totalSize))
+	}
+}