fix(linux): _start never passed envp, and getenv could not even link

[zemo-g]

Two commits. The second was found by following the first.

1. _start never passed envp

It computed argc into x0 and argv into x1 and left x2 untouched.
_main's prologue then stored that garbage into _rail_envp, and
_rail_shell handed it to execve. Every Linux Rail program that shelled
out ran with no environment.

One probe, both targets:

	HOME	env vars	cd ~	cat ~/.fleet/token
Linux before	empty	1	/home/zemog/~	empty
Linux after	/home/zemog	17	/home/zemog	reads
macOS	/Users/…	43	ok	reads

macOS always worked because its prologue receives envp in x2 under the
main(argc, argv, envp) convention. A static Linux binary with its own
_start never gets that, and nothing computed it. The Linux initial stack
is argc, argv[…], NULL, envp[…], so envp is argv + (argc+1)*8.

2. getenv could not link, and _getenv was a stub

foreign getenv did not work on Linux, and not subtly: the FFI
string-return path calls _strdup to copy a borrowed C string onto the
Rail heap, and linux_libc.s had no _strdup at all. Anything using
getenv would not build for the Pi.

_getenv was separately a stub returning 0, justified by envp not being
populated at arena-init time, which commit 1 fixes. It now walks envp
comparing NAME=value against the name up to the =, so HOME does
not match HOMEBREW_PREFIX.

Verified on the Pi against macOS:

getenv HOME  ->  /home/zemog     (macOS: /Users/ledaticempire)
getenv USER  ->  zemog           (macOS: ledaticempire)
getenv NOPE  ->  empty           (macOS: empty)
HOMEBREW_PREFIX set, HOME=/correct/home  ->  /correct/home

One claim retracted

The first commit said storing envp in _start unblocks RAIL_ARENA_MB on
Linux. It does not. The Linux _rail_arena_init never consults
_getenv; it uses a statically reserved BSS heap of fixed size, so that
variable would need an mmap path to have any effect there. Corrected in the
second commit. What the envp fix actually unblocks is _getenv itself.

How it surfaced

The long way round. The fleet agent on the Pi could not read
~/.fleet/token, because ~ will not expand without HOME under dash. That
left its auth token empty, which hit a fail-open branch, which meant the
control plane accepted any token or none. Patched at the caller first
(security/fleet-v2-logs-jobs-injection); this is the cause underneath, and
it affects every Linux Rail program that shells out or reads the
environment.

Verification

• Probes above, run on the Pi before and after.
• macOS untouched: 189/189.
• Self-compile fixed point re-verified byte-identical after each change.
• No Linux regression test exists in the macOS suite; the x86_64
  conformance harness would be the place for one.