Challenge 3: Metadata or Message Field? — Possible Solution
====================================================================

(a) An auth token — METADATA. An auth token isn't part of WHAT is
being asked for — it's information about WHO is asking, needed on
essentially every call regardless of which RPC method is being
invoked. Putting it in metadata means every service method's request
message stays focused purely on its own actual parameters, rather than
every single message definition needing to redundantly include an
auth_token field.

(b) The product ID being requested — MESSAGE FIELD. This is the core
substance of the request itself — WHAT is actually being asked for.
It belongs in the typed, schema-defined request message (e.g.
GetProductRequest.id), exactly as Chapter 2/3 defined it — this is not
auxiliary information, it IS the request.

(c) A request-tracing ID used for logging across services — METADATA.
Like the auth token, a tracing ID isn't part of the actual business
request being made — it's cross-cutting infrastructure information
that needs to travel alongside many different kinds of calls (the same
tracing ID might follow a request through GetProduct, then a
downstream CreateOrder call, etc.) without being part of any specific
method's own defined inputs.

THE UNDERLYING TEST: does this value describe WHAT the call is asking
for (message field) or auxiliary context ABOUT the call itself — who's
calling, how to trace it, how to route it — that would otherwise need
to be redundantly duplicated across many different message types
(metadata)?