Exercise 2: Why /api/items/abc/use Fails, and Why It's the Same Kind of Validation as Chapter 5 — Possible Solution
====================================================================

WHAT HAPPENS TO THE REQUEST
------------------------------
Because the route parameter is declared as item_id: int, FastAPI attempts to parse the "abc" segment of the URL as an integer before ever calling mark_used. Since "abc" cannot be interpreted as a valid integer, FastAPI rejects the request with a 422 response describing the type mismatch - the mark_used function's own body is never invoked at all for this request.

WHY THIS IS THE SAME KIND OF VALIDATION AS CHAPTER 5
------------------------------
Chapter 5's ItemCreate schema validated the shape and types of an incoming JSON request body before create_item's own code ran, based purely on the declared type annotations in that schema. Here, the exact same underlying mechanism - FastAPI validating a declared type before the route's own code executes - applies to a path parameter instead of a request body. The location of the value being validated differs (a URL segment vs. a JSON body), but the principle is identical: declaring a type is itself the validation, and a value that doesn't match never reaches the function's own code.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that item_id: int causes FastAPI to reject a non-integer path segment automatically with a 422, before the function body runs, and correctly identifies this as the same underlying validate-before-the-function-runs mechanism Chapter 5 already established for request bodies, just applied to a different part of the request.