Challenge 3: Trace a Bug Across Tools — Possible Solution
====================================================================

Two genuinely different things worth checking before assuming it's an
API bug:

1. STALE OR MISMATCHED VARIABLES BETWEEN THE TWO TOOLS. Per this
   chapter's own closing gotcha, Postman's environment and the .http
   file's http-client.env.json are two completely independent stores
   of "current state" — nothing keeps baseUrl, an auth token, or any
   other variable automatically synced between them. If the .http
   file's environment still has an old/expired token or a stale
   baseUrl that Postman's environment was more recently updated to fix,
   the .http file would fail for a reason that has nothing to do with
   the API itself — it's testing against outdated values. Comparing
   both environments' current variable values side by side is a fast,
   concrete first check.

2. A DIFFERENCE IN WHAT'S ACTUALLY BEING SENT — specifically headers or
   Content-Type. Postman may be auto-setting a header (e.g. Content-
   Type: application/json, set automatically when choosing "JSON" from
   the raw body format dropdown per Chapter 2's gotcha) that the .http
   file's request is missing, if it was hand-written without that
   header explicitly included. Using the REST Client's own request
   inspection (or comparing against a "Copy as cURL" export from
   Postman's own Network-tab-equivalent, or the browser's Network tab
   if either request path passes through one) to directly compare the
   two requests byte-for-byte — rather than assuming both tools built
   an identical request just because they were configured with
   "the same" values — is the concrete way to rule this in or out.

Both checks share the same underlying principle: when two tools
disagree on the same nominal request, the discrepancy is very often in
how each tool independently stored or constructed that request, not in
the API being tested.