Exercise 2: deleteTask(_:context:) and Why No Explicit Save Step Is Needed — Possible Solution
======================================================================================================

func deleteTask(_ task: Task, context: ModelContext) {
    context.delete(task)
}

WHY NO EXPLICIT "SAVE" STEP IS NEEDED: SwiftData's real ModelContext
is designed around real, automatic saving behavior by default -
unlike some older persistence APIs that require an explicit save()
call before a change actually reaches disk, ModelContext genuinely
tracks changes (inserts, updates, and deletions like this one) and
automatically persists them to the underlying real Core Data-based
store on Apple's own real, scheduled autosave behavior, without the
caller needing to remember and issue a separate save call every single
time.

This mirrors the same general principle Fundamentals Chapter 6's own
@Observable already established for in-memory state: the developer
describes WHAT should change (here, "delete this task from the
context"), and the framework itself handles making that change take
effect and stay effect - in this case, actually persisting it to real
disk storage - rather than requiring separate, manual bookkeeping
steps for every single mutation.

(A real save() method does still exist on ModelContext for cases
needing more explicit, immediate control over exactly when a write
happens - but it's optional for the common case, not a required step
after every single change the way it would be in many older, more
manual persistence APIs.)

ANSWER: context.delete(task) removes the task from the ModelContext,
and SwiftData's own real, automatic saving behavior persists that
change to disk without requiring an explicit save() call - a
deliberate design choice removing a whole category of "forgot to save"
bugs that older, more manual persistence APIs were prone to.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly implements the real deletion call and explains
SwiftData's own genuine automatic-persistence design, rather than
assuming an explicit save step exists just because other persistence
frameworks commonly require one.