Challenge 1: Channel vs. Call Credentials — Possible Solution
====================================================================

CHANNEL CREDENTIALS (TLS, via grpc.credentials.createSsl()) secure the
TRANSPORT ITSELF — the actual network connection between client and
server. This is established ONCE, when the channel/connection is
created, and applies to every single call that travels over that
channel afterward. It answers "is this connection encrypted, and is
the server who it claims to be?" — nothing about WHO is making any
particular call within that connection.

CALL CREDENTIALS (the bearer token attached as metadata) establish WHO
is making a SPECIFIC call, and are attached separately on each
individual RPC invocation (or automatically via a client interceptor,
per Chapter 6). This answers "is this particular caller allowed to
make this particular request?" — a question that's independent of
whether the underlying connection is encrypted.

WHY BOTH ARE NEEDED: they answer genuinely different questions. A
channel could be perfectly encrypted (TLS working correctly) while
still allowing an unauthenticated or unauthorized caller through, if
there's no call-credential check — the encryption says nothing about
WHO is calling. Conversely, a valid bearer token sent over an insecure
(unencrypted) channel would still be exposed in plaintext to anyone
observing the traffic, since call credentials don't protect the
transport itself. This is exactly why this chapter frames them as two
independent, LAYERED concerns rather than one combined "security"
setting.