Guard NavigationLink destination inits against deleted @Models

A closure-based NavigationLink builds its destination view eagerly for
every row on every parent-list body evaluation — including the view-graph
update SwiftUI runs the instant SyncEngine.delete does context.delete +
save. Mapping the row's just-deleted @Model to a document there reads a
persisted property on a dead model, which traps in SwiftData
(_InitialBackingData.getValue -> assertionFailure). This is the "Crashed
when deleted a workout" TestFlight report on 2.3 (124).

Add WorkoutDocument(fromLive:) (nil when isDeleted) + a .deletedPlaceholder
and route every destination-init / updatedAt-absorb map through it:
phone WorkoutLogListView + SplitDetailView (read split.id) and watch
WorkoutLogListView. Fixes the whole crash class, not just the report.

Claude-Session: https://claude.ai/code/session_01BQcEWmAPA78338QuEwRkAh

Workouts/Views/Splits/SplitDetailView.swift

@@ -29,7 +29,12 @@ struct SplitDetailView: View {
     @AppStorage("weightUnit") private var weightUnit: WeightUnit = .lb
 
     init(split: Split) {
-        _splitID = State(initialValue: split.id)
+        // A closure-based `NavigationLink` builds this destination eagerly for every
+        // row in the parent list, including during the update that fires when a split
+        // is deleted — and reading any persisted property (even `id`) on a deleted
+        // `@Model` traps. An empty id maps to no live split, so `body` shows the
+        // "Split Unavailable" state and dismisses; the row is on its way out anyway.
+        _splitID = State(initialValue: split.isDeleted ? "" : split.id)
     }
 
     private var split: Split? {