Expand the README

[tigerblue77]

+78 lines, and purely additive: not one line of your README is changed or removed.

The first version of this was +337 and rewrote the file. 303bee7 and 8edc5dc have since covered the EOL context, latest vs dev-latest, UNCERTIFIED_DRIVES, the _FILE variables and dropping the port publish — so all of that is gone from here rather than restated in different words.

What is left is what is currently only answerable by reading the Dockerfile, or by asking you:

• which servers work — the question people actually arrive with. Your EOL link says the final release "supports 14th, 15th, and 16th-Generation servers", which reads as a floor and is a ceiling, and leaves anyone on a 13th-generation box guessing. It has an answer rather than an opinion: srvadmin-omilcore ships syslist.txt, and CheckSystemType refuses to start the data engine on a system identifier absent from it. Read out of the exact RPM this image installs, that file carries the whole 13th generation (0602=PET630 among them) and reaches back into the 11th. The table says so, and says plainly that recognised is not supported and that storage is the half most likely to have rotted;
• why amd64 only, with the count rather than an assertion: forty packages, all x86_64, no source, end-of-life;
• what the host has to provide, and why each part — --privileged, --cgroupns private, and the three sets of kernel modules the /lib/modules mount exists to supply, one line each. The run command asks for all three today without saying what they do, so the first thing anyone trying to narrow the grant does is guess;
• the web interface — https on a self-signed certificate named after a container ID, so every first visit produces two browser warnings that look like something is wrong. Both are expected, and omconfig preferences webserver regenerates it for a real name;
• troubleshooting by symptom, because somebody reading it has a symptom rather than a cause. The dell_rbu entry earns the section: the error looks fatal, is cosmetic on most hosts, and is genuinely fatal on XCP-ng, and the way to tell which case you are in is whether 1311 answers. Separating it from the modules OMSA actually reads through is what turns "it comes up and every table is empty" into a different problem from "it does not come up".

Authored by me with Assisted-by: Claude, per your answer on #31.