Name check rate limits are easy hit and UX permits bypassing

A follow on from #5716 where the debounce was increased and the rate limit slightly nudged up to lesssen the chance of hitting issue #5703

This follow up is to adresss the overall UX.

As it stands, it is possible to do the following:
* slow typing can easily hit the rate limit
* when the rate limit is hit, the user MUST change what they typed (i.e. it is not rechecked)
* Also, at this point, there is no re-check, so if what the user entered was the value they wanted, they must make a change get another name-check
* If a "good" name is entered and the name check succeeds, it is trivial to paste a "bad" name and operate the "next" button. NOTE: this is not catastrophic as the name is verified and rejected on step 3.

There are a number of ways to solve this but my suggestion would be...
1. Disable the next button on every key change (including paste/cut/delete)
2. Stop the user typing (disable the input) when `x-ratelimit-remaining` === `0` (or `1`)
1. Show a "please wait" spinner for the duration of `x-ratelimit-reset`
1. Re-enable the text field after the duration of `x-ratelimit-reset`.
1. Recheck the entered text after the duration of `x-ratelimit-reset`

> - The Next button should be disabled upon every key stroke & only re-enabled upon successful name check. As it stands, a user can type a "good" name, wait for a check to succeed, then enter a "bad" or "used" name and the next button remains enabled long enough to get to next step. While this IS caught on step 3, it is not ideal UX.
> - We should use the utilise the `x-ratelimit-???` headers to control the UX

_Originally posted by @Steve-Mcl in https://github.com/FlowFuse/flowfuse/pull/5716#pullrequestreview-2978776733_