KubeUI 0.4.0-1.21.1

Port of 0.4.0 to NeoForge 1.21.1 (KubeJS 2101.7.2-build.368) - full feature parity with the main
0.4.0 branch (see github.com/Zynora-fr/KubeUI for the
complete feature list: economy, machines & automation, world map, dialogue, storage, progression,
combat & status HUD, structures & dungeons, guilds & factions, social, housing & claims, settings
hub, the machine screen redesign, JS-only slash commands for guild/party/housing, the tabbed social
screen, custom leaderboards, scriptable guild/party rules, and KubeUIHud), rebuilt against
1.21.1's own real APIs. Real, version-specific adaptations along the way (not guessed - each
verified against this exact NeoForge 21.1.248/KubeJS 2101.7.2 build):

• ResourceLocation (26.1.2's Identifier is this version's Identifier... this version is
  ResourceLocation - the rename only exists going the other way) - same API surface otherwise
  (tryParse/fromNamespaceAndPath/withDefaultNamespace all real here too).
• Block entity persistence is the pre-ValueInput/ValueOutput saveAdditional(CompoundTag, HolderLookup.Provider)/loadAdditional(...) shape; CompoundTag itself has no getXxxOr(...)/
  getListOrEmpty(...)/getCompoundOrEmpty(...) convenience API at all on this version - not even
  through KubeJS, which doesn't add it either (26.1.2's CompoundTag gained these natively as real
  Mojang methods, nothing KubeJS-specific). KubeUINbtCompat reproduces the 26.1.2 semantics for
  this project's own Java call sites; KubeUINbtView (a real public class, since KubeJS's own
  CompoundTag-to-JS conversion falls back to normal reflection for any method name that isn't
  itself a stored NBT key) does the same for scripts - every JS-facing touchpoint that used to hand
  out a raw CompoundTag (KubeUIActionHandler#handle, KubeUIRemoteScreens#register, and a
  handful of KubeUIActions methods like .claimsOf/.guildMembers/.playerData) hands out this
  wrapper instead, so a script written as data.getStringOr('key', 'fallback') works unmodified
  either way. KubeUINbtView also implements KubeJS's own NBTSerializable so the reverse
  direction - a script handing one straight back into KubeUIActions.openRemote(...) - serializes
  correctly instead of silently dropping the value.
• The currency ledger's KubeUICurrency.load(server) no longer clears already-registered
  currencies: on a singleplayer/integrated server, server_scripts top-level code (where
  KubeUIActions.registerCurrency(...) normally lives) runs before ServerAboutToStartEvent
  fires this, so clearing it here was wiping out every currency a script had just registered
  (/money balance always reporting "no currencies registered" was the real, reported symptom).
  Same fix landed on the main 0.4.0 branch - this wasn't 1.21.1-specific, just first caught here.
• AbstractContainerScreen's real override points are renderBg(GuiGraphics, float, int, int)/
  renderLabels(GuiGraphics, int, int) (different names and argument order from 26.1.2's
  extractBackground/extractLabels); a plain Screen subclass's is render(GuiGraphics, int, int, float). GuiGraphicsExtractor (this project's existing 26.1.2-API-shape compatibility
  shim over the real GuiGraphics) is constructed explicitly at each of these bridge points.
• ClickType (not ContainerInput) for AbstractContainerMenu#clicked; Commands.LEVEL_GAMEMASTERS
  is a plain numeric op-level constant with no Commands.hasPermission(int) static helper - real
  permission gating is .requires(source => source.hasPermission(Commands.LEVEL_GAMEMASTERS)) (JS
  commands) / player.hasPermissions(level) (plain Java) instead.
• Item#getBurnTime(RecipeType)/AbstractFurnaceBlockEntity.isFuel(...) (no Level#fuelValues()
  registry yet) for the machine block's real furnace-shaped fuel slot; BlockEntityType.Builder.of( factory, blocks...).build(null) (no bare public constructor yet) for block-entity-type
  registration; DeferredRegister.Blocks#registerBlock(name, factory, Properties) takes a plain
  Properties, not a Supplier<Properties>.

No functional or content changes versus the main 0.4.0 branch.