# DF-5659 — vkernel64 global.s exports 8 gd_CMAP*/gd_PMAP1/gd_CADDR*/gd_PADDR1 aliases via GD_PRV_* macros for fields that DO NOT EXIST in the vkernel64 `struct privatespace` — un-restorable silent-vanish dangles (stale i386 lineage)

Twin/sibling of DF-5658, split out because the remediation differs:
these 8 cannot be fixed by adding ASSYM lines (the fields are absent from
`sys/platform/vkernel64/include/globaldata.h:107-114` — `struct privatespace`
holds only `mdglobaldata` + filler + idlestack, no `prv_CMAP*/CADDR*/PMAP1/
PADDR1`), so the only correct fix is deleting the aliases.

## Evidence

Identical run as DF-5658 (same guest, same VKERNEL64 build tree, same rules —
full pack in `../DF-5658/`):

- `nm_global_pristine.txt`: `U GD_PRV_CMAP1/2/3`, `U GD_PRV_PMAP1`,
  `U GD_PRV_CADDR1/2/3`, `U GD_PRV_PADDR1` in the real-rule-built `global.o`;
  the `.globl gd_CMAP1, …` exports (global.s:77-78) are **absent** from nm.
- `final_binary_baseline.txt`: all 8 ride into the linked vkernel64 binary
  as zero-relocation undefined symbols; link exit 0.
- `fix.diff` (shared with DF-5658, validated): deletes global.s:77-78 and
  the 8 `.set` lines at global.s:86-93 → `final_binary_fixed.txt`: zero
  undefined GD_* of any kind, link green.

## Why it matters

Same silent-vanish mechanism as DF-5596/DF-5658, but these 8 are *actively
misleading*: the pc64 twin has no such block (it is i386 heritage), a
maintainer "restoring the missing ASSYMs" hits a compile error on exactly
these (no field to offsetof), and the exports have been dangling in every
VKERNEL64 build ever made with zero diagnostics. Dead-code removal + the
DF-5658 guard restore together make the genassym↔global.s contract total
(26/26 macros accounted for).