Challenge 1: Preventing a Double-Submit — Possible Solution
====================================================================

it("disables the Log In button while the request is pending", async () => {
  render(<LoginForm />);

  await userEvent.type(screen.getByLabelText("Email"), "ada@example.com");
  await userEvent.type(screen.getByLabelText("Password"), "hunter2");
  await userEvent.click(screen.getByRole("button", { name: "Log In" }));

  expect(screen.getByRole("button", { name: "Signing in..." })).toBeDisabled();

  expect(await screen.findByText("Welcome, Ada!")).toBeInTheDocument();
});

WHY THIS WORKS AS AN ANSWER
------------------------------
This reuses the exact same MSW setup as the chapter's own success-path
test (the default handler returning { name: "Ada" }) — no new server
setup needed, since the pending state occurs regardless of what the
eventual outcome is; the disabled check simply needs to run BEFORE the
request resolves.

getByRole("button", {name: "Signing in..."}) locates the SAME button
element, now identified by its changed accessible name during the
pending state — this only works if the button's text actually changes
to "Signing in..." while disabled, which is exactly what the chapter's
own capstone test already established as LoginForm's real behavior.

.toBeDisabled() is a jest-dom matcher checking the disabled HTML
attribute — a genuinely user-relevant check, since a disabled button
cannot be clicked again, directly preventing the double-submission this
challenge is about. Following up with the same findByText("Welcome,
Ada!") assertion from the chapter's own test confirms the button
becomes usable again (implicitly, by virtue of the flow completing
normally) once the request actually resolves, rounding out the full
pending-to-resolved lifecycle in one test.