Exercise 2: A DownloadTracker Actor, and Why Reading Its Property Needs await — Possible Solution
=========================================================================================================

actor DownloadTracker {
    private(set) var activeDownloads = 0

    func start() {
        activeDownloads += 1
    }

    func finish() {
        activeDownloads -= 1
    }
}

// Usage from outside the actor:
let tracker = DownloadTracker()
await tracker.start()
print(await tracker.activeDownloads)
await tracker.finish()

WHY READING activeDownloads FROM OUTSIDE REQUIRES await: An actor's
own real, defining guarantee is that only one piece of its own code
runs at a time, no matter how many separate real tasks try to access
it concurrently. To make that guarantee actually hold, EVERY access
from outside the actor - reading a property just as much as calling a
method - has to go through the same real, serialized queue the actor
manages internally, rather than reaching directly into the actor's own
memory the way accessing a plain class's property would.

Because that access might genuinely have to wait its turn - if the
actor is currently busy running some other call when
tracker.activeDownloads is read, the read has to wait until the
actor becomes free again - Swift requires await at every external
access point, even one that looks as simple and instant as reading a
single Int property. The await isn't hinting at network or disk
latency here, the way it typically does elsewhere in this course
(Fundamentals Chapter 9) - it's specifically reflecting the real,
possible wait for the actor's own serialized turn.

Code running INSIDE the actor's own methods (like activeDownloads += 1
inside start() itself) doesn't need await, since it's already running
on the actor's own turn - the requirement applies specifically to
crossing the boundary from outside the actor in.

ANSWER: Reading tracker.activeDownloads from outside the actor requires
await because every external access - reads included, not just method
calls - has to go through the actor's own serialized queue to preserve
its real one-at-a-time execution guarantee. The await here reflects a
possible wait for the actor's own turn, not network latency, and only
applies when crossing in from outside; code already running inside the
actor's own methods needs no such await.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly implements the requested actor and explains the real,
specific reason external property access needs await - serialized
access enforcement, not an arbitrary syntax requirement.