fix: correct ESP size docs (64MB->32MB) and document boot modes

The build produces a 32MB ESP (mkfs.vfat 32MB, sed patches
partition->len to 65536) but the README and INTERFACES.sh still
claimed 64MB. The mismatch came from the early 64MB->32MB commit
chain that updated code but not docs.

Fixed:
- README.md partition table: 64 MB -> 32 MB
- INTERFACES.sh line 33: 64MB -> 32MB
- INTERFACES.sh line 189 comment: 64MB->32MB and 32MB/64MB

Also added a 'Boot modes (current)' section to README explaining:
- Direct (chain) and Memdisk modes are available in the deployed binary
- The 'hiso_hv_mode' hypervisor trigger is in in-tree rebrand sources
  (src/grub2/) that are not yet compiled - the supporting payloads
  (initramfs, OVMF, QEMU) are built and in the ESP, only the GRUB
  module rebrand is pending.

Cleaned up:
- Removed empty root-level installer/ directory (src/installer/
  is the canonical source, copied to build/payload/ at build time)
- Removed empty host/qemu/ directory
- Deleted stale .o build artifacts from logging/hiperiso-log/

INTERFACES.sh

@@ -30,7 +30,7 @@ HIPERISO_NET_DUMP=""        # "1" = add virtio-net + pcap capture to network.pca
 
 # ── USB Partition Layout ─────────────────────────────────────────────────────
 DATA_PART="/dev/sdX1"       # Partition 1: Data partition (exFAT/NTFS, rest of disk)
-EFI_PART="/dev/sdX2"        # Partition 2: EFI System Partition (FAT16, 64MB)
+EFI_PART="/dev/sdX2"        # Partition 2: EFI System Partition (FAT16, 32MB)
 EFI_MOUNT="/mnt/efi"         # Mount point for ESP during install
 DATA_MOUNT="/mnt/usb"        # Mount point for data partition at runtime
 
@@ -186,8 +186,8 @@ HIPERISO_JSON="${DATA_MOUNT}/hiperiso/hiperiso.json"
 #      The label and file are produced by scripts/package_release.sh.
 #
 # Modsrc patches: scripts/build_grub2_204.sh applies a single sed
-# pass to the unpacked modsrc tree to (1) accept a 64MB ESP (modsrc
+# pass to the unpacked modsrc tree to (1) accept a 32MB ESP (modsrc
-# hardcodes 32MB / 65536 sectors) and (2) tolerate the missing 0x22
+# hardcodes 64MB / 131072 sectors) and (2) tolerate the missing 0x22
 # GPT-MBR marker byte. (The 0x22 marker is written by the installer
 # in HiperisoWorker.sh — not by the build.) Anything beyond these
 # patches is upstream Ventoy territory; do not modify modsrc without

README.md

@@ -117,7 +117,7 @@ layout is:
 | # | Type   | FS     | Size   | Contents                                   |
 |---|--------|--------|--------|--------------------------------------------|
 | 1 | 0700   | exFAT  | rest   | Your ISOs + boot logs + config             |
-| 2 | EF00   | FAT16  | 64 MB  | ESP: GRUB2, kernel, initramfs, OVMF        |
+| 2 | EF00   | FAT16  | 32 MB  | ESP: GRUB2, kernel, initramfs, OVMF        |
 
 Copy your ISOs:
 
@@ -144,6 +144,25 @@ sudo bash Hiperiso2Disk.sh -i -L MYUSB /dev/sdX # custom data-partition label
 4. The ISO's OS boots **unmodified** inside the VM.
 5. On guest shutdown, logs are flushed to the data partition.
 
+### Boot modes (current)
+
+The deployed binary supports two boot modes selectable from the GRUB menu:
+
+| Mode | How to select | Behavior |
+|------|---------------|----------|
+| **Direct (chain)** | Default menu entry | Boots ISO via Ventoy-style chain (small ISO read into RAM, KVM/QEMU launched by the host kernel). |
+| **Memdisk** | Default fallback when chain fails | Loads the entire ISO into RAM, then boots via `memdisk`. Confirmed working. |
+
+The `hiso_hv_mode=1` "hypervisor" trigger (the killer feature that boots
+ISOs through a Type-1 hypervisor path with full bootlogging) is defined
+in `src/grub2/hiperiso_cmd.c` and `hiperiso_boot()` in `grub.cfg`, but
+those code paths are in the in-tree rebrand source that is **not
+currently compiled** — we build the GRUB module from the vendored Ventoy
+modsrc, which doesn't have them. The initramfs + host kernel + QEMU +
+OVMF payloads are built and in the ESP (see `build/payload/EFI/hiperiso/`),
+so the infrastructure is ready. The remaining work is completing the
+rebrand of the GRUB module to expose the hypervisor menu entry.
+
 ### View boot logs
 
 Every boot gets its own timestamped session directory so logs are never