The panel sends a redirect only when somebody changed it

[kisielewski]

The other half of AlgoJudge/AlgoJudge-Server#96, and the half that actually fixes it.

settingsOf said this form knows the whole answer, so it says so and always
sent both redirect fields, blank when absent. It did not know the whole answer:
it reads getInstanceInfo, where a redirect naming a switched-off provider is
filtered away. So on an installation whose provider was down for an hour of
maintenance, saving anything on that tab cleared both columns, and re-enabling
the provider did not bring the redirect back.

Two halves.

The panel reads the columns from getInstanceRedirects and shows them
truthfully. A stored slug the provider list does not carry is offered as a
marked, selected option — switched off, so the screen draws itself, or no
provider is registered under this — with an Alert under that field saying what
is happening and how to undo it. Only ever the stored value: offering an
arbitrary disabled provider would let somebody aim a redirect at a 404, which is
what the Server's 422 exists to refuse.

And it omits a redirect field it did not change. Absent means leave it alone,
which is the only honest thing a form can say about a value it may not be able to
see — and it closes a second hole for free: Instance has two writers, so an
always-sender overwrites a change made by aj-admin config apply with a value
read when the tab was opened.

settingsOf losing the two fields is load-bearing, not tidying: the effect
following instance re-seeds it from the filtered answer on every
instanceChanged, including the one this screen's own save causes.

The fake stopped stating its providers twice. The instance's list and the
manager's registrations were written out separately and happened to agree, so
switching a provider off in the panel changed nothing a screen saw. The list is
now projected from the registrations, and ?fakeProviders=off empties the
fixture rather than one half of it.

What the browser found that reading did not

• An aborted read counted as a failure. useApiEffect already ignores a
  request its own cleanup cancelled, but a catch inside the effect swallows it
  first — so under React's development double-invoke the screen drew a value it
  had read and a note saying it could not read one, side by side.
• A picker whose option list had not caught up drew its placeholder. Writing
  a provider announces nothing, so the list lags in both directions; the stored
  slug is added whenever the list does not already carry it.

And three assertions that passed for no reason

Worth stating, because each was green before it was right:

• a needle written znak w aplikacji matched nothing — the Polish label carries
  a hard space after w, because Polish does not leave a one-letter word at
  the end of a line;
• \s inside a template literal loses its backslash, so the browser was sent
  /s+/g and replaced the letter — the same defect this repository fixed in
  verify-external-content last week, and the file's own drawn() already
  writes \\s;
• the sign-in screen no longer offers the provider passed on a screen that had
  not drawn. Removed rather than repaired: the manager walk runs signed in,
  so /login answers with a redirect and there is nothing to read. The file says
  so where the assertion used to be.

Three sabotages, each reddening the walk — including putting always-send back,
which now fails on the save itself went through: the old form is refused,
No enabled identity provider is registered under "university", so the setting
would have survived for the wrong reason.

lint, lint:deps, typecheck, build, check:i18n, check:api against the
regenerated document, and the seven other checks. Full check:ui: 51 of 51.