Challenge 3: What's Actually Portable in Each Case — Possible Solution
====================================================================

In C, "the source code is portable" means the .c FILE ITSELF -- the
human-readable text -- can, in principle, be taken to a different
machine and compiled there successfully, ASSUMING that machine has a
compatible compiler and no platform-specific code was used. But what
actually gets PRODUCED by compiling it -- the real, final executable
binary -- is tied permanently to the specific CPU architecture and
operating system it was compiled FOR. A binary compiled for Linux/x86
will not run on Windows or on an ARM-based machine at all; using that
same C program on a different platform genuinely requires
RECOMPILING the source there, using that platform's own compiler
toolchain, producing an entirely separate binary.

Java's "write once, run anywhere" claim is about something different:
the COMPILED ARTIFACT ITSELF -- the .class bytecode file produced by
javac -- is what's portable, not just the source. The exact same
.class file, produced by ONE javac compilation, can be copied to
Windows, Linux, or macOS and run unmodified via each platform's own
`java` command, with NO recompilation step required on the target
machine at all.

What still has to happen on the target machine either way: in BOTH
cases, something platform-specific still needs to exist locally.
For C, that's a compatible COMPILER able to produce a binary for that
specific platform. For Java, that's a JVM implementation for that
specific platform, capable of interpreting/JIT-compiling the SAME
bytecode file into that platform's own real machine instructions at
runtime. Neither approach eliminates the need for SOME
platform-specific software to exist on the target machine -- what
differs is WHERE the platform-specific step happens (recompilation of
source, for C; interpretation/JIT of already-compiled bytecode, for
Java) and WHICH artifact has to be re-created for each new platform
(a full new binary, for C; nothing at all, for Java, since the JVM
handles the platform difference and the same .class file is reused
unchanged).

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies WHICH artifact is portable in each model
(source vs. compiled bytecode) and explains that both models still
require SOME platform-specific software present on the target machine
(a compiler vs. a JVM) -- the real distinction is where the
per-platform step happens and whether it has to be repeated for every
new platform, not that one model magically requires nothing platform-
specific at all.