Third step, `font-src 'self'` is now possible.

Turn it into the identity function because I completely messed up the
URL highlighting due to replacing the OOC chat lines with plain text
rather than them getting appended to the inner HTML.

Similar to removal of inline scripts, everything was taken out into the
CSS files, with the same styles applied there directly. This lets us
use `script-src 'self'` in the CSP.

Additionally, serve Golden Layout CSS locally to avoid third-party
connection.

The next layer after input validaton to achive the paranoid levels of
security. Remove all event handlers inside HTML attributes and add them
in TS for each element, allowing `script-src 'self'` to be used as a CSP
directive.

Buttons that passed some value and had a shared function went into
a global listener with data-action attribute, while all the individual
elements received their own event listener. This is a mess, but my goal
was to end up as close as I could to one-to-one translation of how
functions were originally attached to elements.

Following the removal of innerHTML manipulation, we no longer need these
sanitization functions.

I've reviewed every safeTags call site to make sure the outputs don't
end up anywhere unsafe, and malicious input can't malipulate DOM or
execute code. These values either end up either as plain text
(textContent, innerText, createTextNode, title, option) or as a URL
path to request assets to the server (encoded using encodeURI).

That is, if safeTags was even effective, considering all that function
did was replace '<' and '>' symbols with Unicode lookalikes. Even the
comment was suggesting the use of fundamentally safer functions instead
of these hacks.

Replace remaining uses of prepChat with unescapeChat as we still need
to do the token substitution (like "<and>" to "&"). decodeChat was
escaping Unicode sequences like \uXXXX, but I don't see the reason for
this, AO2 Client doesn't have this feature, and considering WebSocket
text frames are strictly UTF-8, we don't need these encodings.

Construct DOM nodes directly instead of trying to sanitize every input
string and dynamically updating HTML.

Replace all uses of innerHTML with textContent, replaceChildren, and
appendChild.

This removes the need to use safeTags and replace newlines, but now
requires preserving whitespace via CSS pre-wrap.

Every OOC chat line is now placed into its own element instead of simply
being appended to the log. This might be worse, and createTextNode
is another alternative.

Bring in the subprotocol (the same as what's used on the desktop client
for public-key authentication) to carry the relevant messages:

- AuthRequest: first step in the flow, the client sends it to signal the
  intent to authenticate to the server.

- AssertCredential and AssertionFinish: server's challenge and client's
  response, respectively, to finalize the flow.

- RegisterCredential and RegistrationFinish: same structure as the
  above. Unlike the simple public-key auth with an out-of-band setup,
  passkeys require user interaction to register. User must be
  authorized.

Validate all relevant checks on the API side, and hand the data over to
the server for it to verify attestations and assertions.

Because it's a primary auth mechanism (not a second factor), require
user verification.

As we don't use any other method on web, add a passkey button as the
only sign-in interface. Passkeys are discoverable, we don't even need a
username.

The hCaptcha integration has been abandoned for a while. It added yet
another questionable third-party API (which also set a Cloudflare
cookie), and its effectiveness is unclear considering its client-side
nature.

A custom CAPTCHA implementation (such as PoW challenge) is an
interesting prospect, but it'll require proper server-side support.