not to be confused with the Minecraft technical update
I'm moving about the pages to be have a more flat, less nested structure.
I feel like that'll improve URLs a lot, making them more readable than ever.
over the years I've learned that flatter is better, and that tagging is generally a much more effective way of organising things.
this doesn't get rid of categories entirely, as I think having the category makes the URL much a bit more readable in the end.
my current vision does include a concept of "major categories" either way.
this allows us to serve a precise Content-Type header for all our pages, rendering treehouse usable in browsers that require one
(like terminal browsers---w3m, lynx)
since initiating the whole liquidex -> riki thing, I've decided that disconnecting myself from "rikiddo" is probably gonna be for the better, and I'm slowly beginning to take on the moniker "riki moe."
client-side time zone adjustment still persists---the server renders them out in UTC, but the client will adjust the date to its timezone during loading.
this shouldn't cause any layout shifting because we use `font-variant-numeric: tabular-nums` (though Recursive seems to use tabular numbers either way.)
to accomplish this, I generalised emoji tooltips to a shared Tooltip class.
in the long run I'd like to transform all existing `title=""` tooltips into these for stylistic consistency with the rest of the website, but this is good enough for now.
I also ended up cleaning up some old code from before the /b rework.
branch permalinks still use /b, but /b?abc now acts as a redirect rather than doing annoying JavaScript garbage
I changed the branch element ID format to accomodate this---now the IDs are of form `b-{id}` rather than `{tree_path}:{id}`.
the old way was stupid anyways.
I hope nothing breaks too majorly because of this.
based on a very simple reading of the SVG's XML to find out its `width`, `height` and `viewBox`
no further parsing is required or will be provided
and you are an excellent test subject
this gives us a _much_ easier time with composing file systems, since you can call `query` on the inner file system and all the magic will be done for you
the overhead is technically slightly higher, but seems to be drowned out by other more expensive stuff; i couldn't measure a difference in my traces
