docs: readme installer options and plain wording

The quick install block gains the PowerShell form that passes options and a link to the installer page. The collection size uses the GB format of the download table and the site, counts get separators, and the sentences about RetroArch's existence check and the method describe the code instead of judging documentation.

README.md

@@ -27,9 +27,13 @@ curl -fsSL https://raw.githubusercontent.com/Abdess/retrobios/main/install.sh |
 # SD card mounted on a PC: --dest is the BIOS folder on the card
 # (RetroArch on Switch: retroarch/cores/system, on Android: RetroArch/system)
 curl -fsSL https://raw.githubusercontent.com/Abdess/retrobios/main/install.sh | sh -s -- --platform retroarch --dest /path/to/sdcard/retroarch/cores/system
+
+# Options in PowerShell: anything after | iex goes to iex, so the script runs as a block
+&([scriptblock]::Create((irm https://raw.githubusercontent.com/Abdess/retrobios/main/install.ps1))) --check
 ```
 
 The script auto-detects your platform, downloads only missing files, and verifies checksums.
+Every option, and what the installer detects and writes, is on the [installer page](https://abdess.github.io/retrobios/wiki/installer/#passing-options).
 
 ## Download BIOS packs
 
@@ -65,7 +69,7 @@ The RetroDECK pack already carries its own `bios/` folder, so it extracts into `
 BIOS, firmware, and system files for consoles from Atari to PlayStation 3.
 These are the files an emulator loads from disk instead of carrying inside itself. Some are required to boot a system, others improve accuracy or unlock a feature, and the packs carry both.
 
-Each file is checked the way your platform checks it. Most compare a checksum, the fingerprint of a file's contents, which catches a corrupt or unexpected copy. RetroArch, Lakka and RetroPie only look for the filename, because that is all their code does: the Coverage table says which applies to you. Independently of that, the collection records five fingerprints per file, and wherever an emulator's code states an expected size or hash, that value is read from its source and rechecked here.
+Each file is checked the way your platform checks it. Most compare a checksum, the fingerprint of a file's contents, which catches a corrupt or unexpected copy. RetroArch, Lakka and RetroPie check that the file is present under its name without reading its contents (`path_is_valid` in RetroArch's `core_info.c`): the Coverage table says which applies to you. Independently of that, the collection records five fingerprints per file, and wherever an emulator's code states an expected size or hash, that value is read from its source and rechecked here.
 
 - **936 files** the platforms' emulators load are still to be found, and 136 more cannot be sourced at all (per-user keys, user-filled slots, dumps nobody has made). Both are named in the [gap analysis](https://abdess.github.io/retrobios/gaps/)
 - **12 platforms** supported with platform-specific verification
@@ -73,7 +77,7 @@ Each file is checked the way your platform checks it. Most compare a checksum, t
 - **533 systems** handled by those emulators (NES, SNES, PlayStation, Saturn, Dreamcast, ...)
 - **19,526 files in the collection**, each with its SHA1, MD5, SHA256, CRC32 and Adler-32 fingerprints: 5,743 system files, 2,851 arcade ROM sets, 10,932 game and engine data files. That is every platform and emulator together, so no pack holds them all: each carries what its own emulators load, counted in the download table
 - **555 of 5,743 system files** matched to dump-preservation catalogs (No-Intro, Redump, TOSEC). Arcade sets and engine data fall outside what those catalogs index
-- **16011 MB** total collection size
+- **15.6 GB** for the whole collection
 
 ## Supported systems
 
@@ -146,8 +150,7 @@ The [documentation site](https://abdess.github.io/retrobios/) provides:
 
 ## How it works
 
-Documentation and metadata can drift from what emulators actually load.
-To keep packs accurate, platform lists are checked against emulator source code, file by file where a profile exists. When the two disagree, the code wins.
+A platform's BIOS list and an emulator's code are maintained separately. Each list is compared with the emulator source code, file by file where a profile exists, and where the two differ the code decides.
 
 Hashes document what emulator code loads and accepts, not dump provenance. That boundary, and how it relates to preservation catalogs such as No-Intro, is drawn in the [FAQ](https://abdess.github.io/retrobios/wiki/faq/#are-these-files-verified-against-original-hardware-dumps).