Challenge 1: getByRole vs. getByText for a Button — Possible Solution
====================================================================

screen.getByRole("button", { name: "Save" });

WHY getByRole IS PREFERRED OVER getByText HERE
------------------------------
getByRole('button', {name: 'Save'}) specifically confirms that the
element is recognized as a BUTTON by the accessibility tree — the
exact same way a screen reader or other assistive technology would
identify it — AND that its accessible name is "Save". This means the
test is verifying two things a real user (including one using
assistive tech) actually depends on: that it's interactive/a button
at all, and what it's labeled.

getByText('Save') would match ANY element containing the text "Save"
— a <button>, but also a plain <span>, a <div>, or a <p> that happens
to contain the word "Save" with no interactive behavior at all. If a
future refactor accidentally turned the real button into a non-
interactive element that still displayed the text "Save" (a genuine
regression a real user would notice — they could no longer click it),
getByText('Save') would still find it and the test would still pass,
completely missing the regression. getByRole('button', ...) would
correctly fail in that scenario, because the element would no longer
have the "button" role at all — exactly the kind of behavior-focused
guarantee this chapter's query priority guide is built around.