port/26.3: build against release 26.3 (Blaze3D.openUri, MultiPlayerGameMode.dropItem, FAPI 0.161.0)

[dewmon689]

port/26.3 currently targets 26.3-snapshot-7 and does not run on release
26.3. Three things are needed; this PR is the two that are unambiguously
version-porting work.

Fabric API floor

0.156.2 no longer loads on release 26.3: content-registries' LivingEntityMixin
fails to inject into isInCustomFluid, and the transitive access widener
targets BlockTransformerMappings / ItemInHandRenderer are gone. 0.161.0 is
the first build that loads cleanly, so dep.fapi and meta.fapi-range are
raised to match, and dep.minecraft moves from the snapshot to 26.3.

Two moved signatures

• Util.getPlatform().openUri(String) no longer exists — link opening moved to
  com.mojang.blaze3d.Blaze3D.openUri(URI). Five call sites in
  GlobalSettingsScreenFactory / ControlifySettingsScreen.
• LocalPlayer.drop(boolean) no longer exists, so the dropresult
LocalPlayerMixin @Shadow fails to apply and the client hard-crashes during
  mixin application. The equivalent is
  MultiPlayerGameMode.dropItem(LocalPlayer, boolean), which drops
  inventory.removeFromSelected(all) and swings, as drop() did. It returns
  void, so the invoker reports what the old return value meant: the drop
  happened iff the selected stack was non-empty beforehand. Both callers in
  InGameInputHandler (DROP_STACK and the repeating DROP_INGAME bind) rely on
  that boolean, and behave the same.

Not included: SDL natives

Worth flagging separately, because it is a design question rather than a port.
With includeNatives off for >=26.3, SDLNativesLoader.load() falls through
loadFromControlifyNatives -> loadFromLwjgl (still a stub returning empty)
-> loadFromNativesInJar (disabled) -> System.loadLibrary("SDL3"), so on any
host without a system SDL3 the mod fails with UnsatisfiedLinkError /
"Could not load SDL natives". MC 26.3 does ship SDL3 via LWJGL 3.4.3
(org.lwjgl.sdl.SDL.getLibrary()), but adopting it is not a drop-in:
SDLControllerManager installs an SDL_SetEventFilter and runs its own
SDL_PollEvent loop, which on a shared instance would sit on top of the
window's own event queue. I left that alone here and kept in-jar natives
locally in order to test; happy to open a separate issue if useful.

Testing

Linux x86-64, Fabric Loader 0.19.5, release 26.3, Fabric API 0.161.0+26.3,
YACL 3.9.6+26.3-fabric. Both runClient and a production jar in a real
launcher profile: 0 mixin failures, SDL 3.4.12 initialised, a Logitech F310
(0x046d/0xC21D) enumerated as a controller, in-game binds and the settings
screens working. NeoForge is untested and unbuildable on this branch, since
dep.neoforge is unset for 26.3 — Fabric only.

Patches written with Claude Code; commits carry a Co-Authored-By trailer.

[DCDCDC1090]

Hey there, I just posted something in regards to this, (I think), I'm new to git and just a dumb person, so bear with me if this is useless info to you. Anyway #985

[isXander]

When porting, for example the Blaze3d.openUri stuff, you need to use preprocessor statements in order to not break older targets.