Fix Discord freeze gate when RPCharacters enables after TFMCWeb

[ryanbarlow97]

TFMCWeb enables before RPCharacters because RPCharacters depends on it. The boot-time availability check cached false permanently, so unlinked Survival players never received RPCharacters' Discord freeze.

Resolve the optional gate API when it is used, cache methods from the enabled RPCharacters plugin instance, and discard them when the plugin is absent or disabled. Remove the reverse soft dependency and replace the misleading startup warning with a waiting message.

Validation:

• Java 21 mvn -B clean verify passed: five regression tests, all failing against the original implementation and passing with this fix. Coverage includes late enablement, eligible players, game modes, offline UUIDs, clearing, and disabled/missing RPC.
• Tested on isolated Paper 1.21.10 build 130 (8043efd), Java 21.0.12, with real RPCharacters 1.1.7, TLibs 1.1.1, MMOCore, MMOItems, MythicLib, MythicMobs and ProtocolLib. A Mineflayer client connected as DiscordGateBot; a read-only probe inspected RPC's gate flag and frozen-player map.
• Startup log confirms TFMCWeb enabled with rpc=false, then RPCharacters enabled, then the gate became available. /web status subsequently reported RPCharacters gate: yes.

Server scenario	Result
Unlinked Survival join	Gate and freeze set; Discord-required/link instructions received; 0 blocks net displacement after three seconds of forward input
API becomes eligible, /web reconcile	Gate and freeze cleared; 12.95 blocks movement
API becomes ineligible again, reconcile	Gate and freeze restored
Unlinked Creative, reconcile	Gate and freeze cleared; 12.95 blocks movement
Return to Survival, reconcile	Gate and freeze restored

The test used a localhost identity API fixture and disabled unrelated character/clue freezes. It validates the actual plugin load order and player freeze/release, not live Discord OAuth or production API behavior. The initial lab setup needed MythicMobs for an existing undeclared RPC utility-class dependency; the successful run had no ERROR/exception entries. The fixture did not implement unrelated character-catalog PUT requests, producing an expected catalog-sync warning. The server was stopped cleanly after testing.

Reviewed the full diff and gate call sites; no blocking findings. No production deployment.

Tested TFMCWeb JAR SHA-256: 6f39cbbbd1299c3fbb7ac38d02bee8fd625eb3a4ffa2ed8d33813812a0bb96aa.