Challenge 2: Why the Validation Test Needs No MSW — Possible Solution
====================================================================

The empty-submission validation check is CLIENT-SIDE-ONLY logic — it's
a check LoginForm itself performs (are the email and password fields
non-empty?) BEFORE it ever makes any network request at all. Since no
request is ever sent in this scenario, there's nothing for MSW to
intercept or respond to — the test never reaches the point where a
mocked "/api/login" handler would even matter.

This is genuinely different from the login-success and login-failure
tests, both of which specifically test what happens AFTER a real
(mocked) request completes — one where the server responds
successfully, one where it responds with a 401. Those tests are
inherently about the response coming back from "the server," so MSW's
job (faking that server) is directly relevant to them.

WHY THIS DISTINCTION MATTERS: it's a concrete illustration of this
course's own testing-pyramid thinking (Chapter 1) applied at a fine
grain within a single component — the validation check is closer to a
pure, synchronous, client-only piece of logic (fast, deterministic,
no async concerns at all), while the success/failure paths are
inherently asynchronous and depend on what "the server" says. Testing
each according to its own actual nature — no unnecessary MSW setup for
the synchronous case, MSW exactly where the async server interaction
genuinely happens — keeps each test as simple as the behavior it's
actually verifying, rather than uniformly wrapping everything in mock-
server ceremony regardless of whether it's needed.