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/

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