I think in traditional Unixes (both the AT&T and the Berkeley ones) the kernel mounts the root file system before starting init. Now, that doesn't mean that it is "guaranteed", in the sense that there is a standards body that says "if you want to be XX-compliant (for example XX=Posix), you have to do it that way". After all, init is co-developed with the kernel, and there are no standards for the interface between the kernel and init. There may be exceptions in unusual systems.
Consider the alternatives: Imagine you are trying to develop a new init. Imagine what you would do if you are started, and there is no root file system mounted yet. If you knew which device it is on, and had all the required knowledge (like mount options, what type of file systems), you could call the mount(2) system call. First problem: That call is not standardized (it's not part of Posix). Second serious problem: How are you going to find this information? You can't look in /etc/fstab, because it it not mounted yet. So if it were possible that init would have to do the mount of the root file system, it would have to get that information from elsewhere. For example as "command line parameters" in argc/argv from its "caller" (usually that would be a shell, in the case of init it's the kernel). For this to work, you'd have to co-develop init with the kernel to pass these parameters. If you do all that work, you might as well have the kernel do the mount - thereby reducing it to a problem already solved.
By the way, where does the kernel get that information from? Special parameters passed in by the boot loader (or a kernel command line if an interactive boot is used). It does not use anything stored solely on the root file system to find the root file system.
Then you ask whether /etc/fstab has to exist, and whether it has to be on the root file system (which is the same question as whether the /etc can be a separate file system). First: if it were on a file system other than root, that would be useless, since the kernel only mounts the root file system, and then the whole init process (the init executable and all the rc scripts) would never find it. Second: I think it is legal to not have an /etc/fstab file; in that case, only the root file system is mounted.
And last you ask: What if the root entry in /etc/fstab doesn't match what is actually mounted, what should your init do? Well, let's consider what it could do. It could for example crash the system deliberately (sort of like an assert), and tell the user in an error message that they misconfigured the system by editing /etc/fstab without updating the kernel parameters. That would be worse than useless, it would turn a small human error into a permanent outage. It could print an error message in syslog or dmesg. That would be somewhat useful, since it at least tells the admin that they did something silly. It could actually remount the root file system the correct way; this is obviously dangerous, since at this point files are already open (and remounting an already mounted file system is rather difficult, look at all the complexity of pivoting root in Linux). For example: what if the new root file system has a different init binary than the one that was used previously, then init knows that it shouldn't be running - but blowing up was already decided to be a bad idea. Exec'ing the new init is at least dangerous (since this init can't be sure how to pass parameters to the new init), and it would turn a minor misconfiguration (wrong entry in /etc/fstab) into a hard crash if the new init doesn't actually work (for example because the other file system is a typo, and not intended to be a root file system, and has something completely different in its directory .../sbin/init which was never intended to be the init program). I think in summary, there is nothing sensible to do if the entry in /etc/fstab is wrong. One of my former colleagues had a good way to describe this situation: "Don't ask a question, if you aren't prepared to handle the answer."
