TEL migration guide: recommend a throwaway kernel argument for clusters already on the newest version

Fast follow to docs#757, which is being merged as part of the Talos Enterprise Linux launch section. Part of #649.

The migration how-to already says that any schematic change moves a cluster to enterprise images on the next upgrade, and it lists the options: bumping the Talos version, adding or removing a system extension, or changing kernel arguments. That is correct and does not need fixing.

What it does not do is tell the reader which of those to pick. Someone already running the newest Talos version has no version to bump to, and the obvious remaining move (add an extension, upgrade, remove the extension, upgrade again) is two upgrades and leaves them wondering whether the extension was supposed to stay.

What to add

A sentence recommending a throwaway kernel argument as the cleanest trigger for a cluster already on the current version, and saying it can be left in place afterwards rather than needing a second upgrade to remove.

Where this came from

Raised in #proj-omni on September 15. The first answer given was to add and then remove the hello-world extension; the better answer, from Utku, was to add a dummy kernel argument instead, precisely because it does not have to be taken back out.

This is the question the first internal person hit on launch day within minutes of the cutover, which is a reasonable signal that customers will hit it too.

Start with the migration how-to described in the issue and find the section listing schematic-change options. Add the recommendation for a throwaway kernel argument for clusters already on the newest version, including that it can remain afterward. Confirm the rendered guide clearly explains this single-upgrade path.