Add freestanding / kernel codegen target to `home build`

[glennmichael123]

Context

`home build` today only emits host-target binaries (Mach-O on macOS, ELF on Linux, PE on Windows). There's no flag to produce freestanding object files suitable for kernel linking.

Audit (2026-05-01) of the home-os kernel found that stages 3 (compile-to-object) and 4 (link kernel image) of the audit could not be tested at all — every kernel module ICEs in host-codegen with errors like:

• `error.FileSystemAccessDenied`
• Double-extension filenames (`foo.home.home`)
• `call to undefined function` for kernel-only intrinsics
• DebugAllocator memory leaks

These are codegen-target mismatches, not per-module bugs. Files that typecheck cleanly (e.g. `arch/arm64/boot.home`) still fail at this stage because the compiler is trying to make them macOS executables.

Proposal

• Add `--target=` accepting at minimum: `x86_64-freestanding`, `aarch64-freestanding`, plus the existing host targets. Triple format aligned with Zig's target syntax is reasonable.
• Add `--kernel` (shorthand): no libc, no host runtime, freestanding ABI, position-independent if requested. Either implies `--target=<host_arch>-freestanding` or is composable with `--target`.
• Make output object-file format selectable (`--emit=obj` to produce a `.o`, `--emit=bin` for a binary). Kernel work needs `.o` files that link with `ld`.
• Wire through to the codegen layer — disable host-OS dependent intrinsics, use freestanding entry-point conventions.

Why this matters

Without a freestanding target, home-os cannot be built with the Home compiler at all — the build dispatcher in home-os falls back to Zig as the assembler/linker, but the Home → object step is the broken link.

Audit reference

`~/Desktop/home-os-kernel-audit-2026-05-01.tsv` on the maintainer's machine; section "Limitations" of the audit report explicitly flags this as the blocker for ever moving past stages 1-2.