fix: remove the silent failure paths around island level

[minoneer]

Callback has no failure channel, so a caller could not tell that its callback would
never run. Each of these sites returned quietly and left whatever it had scheduled
inside the callback permanently pending — with nothing in the console either.

What was silent

ChunkSnapshotLevelLogic.calculateScoreAsync returned without invoking the callback when
WorldGuardHandler.getIslandRegionAt(l) returned null, and logged nothing. Four consumers:

consumer	consequence
/is info	prints nothing, and leaks the 30s patience cooldown so the retry answers "be patient"
/is level	prints nothing when a recalculation is due
IslandInfoEvent	API callback never fires; consumers wait forever
RecalculateTopTen	advances its queue only from inside the callback

uSkyBlock.calculateScoreAsync additionally dereferenced a null IslandInfo.

AbstractPlayerInfoCommand.execute returned false without a word when no player
argument was supplied, and AbstractIslandInfoCommand.execute did the same at its final
return — which is why /usb is info with no argument, off-island, produced nothing.

Approach

LevelLogic.calculateScoreAsync now returns whether the callback will run, and
implementations must log before refusing. Every caller handles the refusal: the commands
tell the player and clear the cooldown, RecalculateTopTen skips the island and keeps
draining, InternalEvents logs.

No branch is left doing nothing. Where a state is unreachable by construction it throws
rather than returning quietly — the sealed doExecute(CommandSender, PlayerInfo) hook
throws UnsupportedOperationException, and a null playerInfo after a successful
super.execute() throws IllegalStateException.

Also repairs a pre-existing regression

RecalculateTopTen extends BukkitRunnable, so scheduler.async(RecalculateTopTen.this)
bound to Scheduler.async(BukkitRunnable) → runTaskAsynchronously →
checkNotYetScheduled(), which throws once the instance has been scheduled — which it has,
by RecalculateRunnable. The success path has thrown since a0404c3e ("Move all
scheduling to Scheduler", v3.2.0), which rebound a plain-Runnable submission to the
BukkitRunnable overload. Both sites now cast to Runnable.

Scope is narrower than it first looks. The auto path is the only affected one:

path	behaviour	affected
/is top, GenTopTenCommand → IslandLogic.generateTopTen	reads persisted islandInfo.getLevel() off disk, sorts, fires RANK_UPDATED	no
island.autoRefreshScore → RecalculateRunnable → RecalculateTopTen	recomputes levels via calculateScoreAsync	yes

So the leaderboard itself was never broken — only the background refreshing of the levels
it sorts, and those still updated whenever a player ran /is level or /is info (the
wrapper calls islandInfo.setLevel(...)). The shipped default autoRefreshScore is 0m,
so on default configuration the affected code never ran at all.

Verified that RecalculateTopTen is the only self-scheduling BukkitRunnable in Core —
the other nine subclasses never reschedule themselves, and IncrementalRunnable (the engine
behind chunk snapshots, generation and purge) implements Runnable, so its
scheduler.sync(this, …) binds to the safe overload.

The failure mode is not merely inferred from checkNotYetScheduled(): it is present once in
production history, from /is reset on v3.2.0-SNAPSHOT in Dec 2025 —
IllegalStateException: Already scheduled as 552. That path has been reworked across three
releases since and static analysis finds nothing on master that could reproduce it, so it is
evidence the mechanism is real rather than a second open bug.

Scope note on IslandInfoEvent

For the other consumers the fix is real. Here the consumer's Callback still never runs
and still has no way to learn that — the event exposes only getIslandLocation() and
getCallback(). The change makes it diagnosable, not fixed. A proper failure channel
needs an APIv2 addition; follow-up worth filing.

Behaviour change worth review

The standing-on-an-island fallback no longer runs when a player name was supplied but
did not resolve. That case already reported an invalid player, and silently retargeting to
wherever the sender happens to stand is surprising.

In practice this was already dead code: the default bukkit PlayerDB resolves any string
through Bukkit.getOfflinePlayer(String), which never returns null, so super.execute()
could not fail with arguments present. Only MemoryPlayerDB could. The one real
consequence is that /usb island get|set require a player name — which they always did.

Compatibility

void → boolean on uSkyBlock.calculateScoreAsync is binary-incompatible for anything
compiled against ovh.uskyblock:uSkyBlock-Core ≤ 3.6.1, which would see
NoSuchMethodError. Accepted deliberately: the stability guarantee covers
us.talabrek.ultimateskyblock.api (uSkyBlock-API), which this PR does not touch, and Core
3.4.2 → 3.5.0 already removed public classes on a minor bump. LevelLogic is Guice-bound
with no third-party registration hook. Worth a line in the 3.7.0 notes.

Notes

AweLevelLogic takes the signature change only; its body is commented out and it throws.

Translation templates regenerated (./gradlew translation) — three new msgids, no other
churn; extractTranslation is idempotent against the committed .pot files, so
build.yml's git diff --exit-code passes.

No new tests. The missing-region failure needs a live island whose WorldGuard region has
been removed, which the harness has no fixture for, and asserting that the boolean is
checked would pin the mechanism rather than the behaviour. The InternalEventsTest stub
change from doNothing() to doReturn(true) is load-bearing, not cosmetic: Mockito's
DoesNothing rejects a non-void method at stubbing time, so doNothing() would fail
@BeforeEach for all six tests.

Coverage gap worth a follow-up: no ittest scenario touches level logic,
calculateScoreAsync, IslandInfoEvent or the top-ten refresh. A scenario that sets
autoRefreshScore, occupies two islands and asserts both levels move would have caught
the a0404c3e regression in 2025, and unlike the missing-region case it is a fixture the
harness can support. A unit-level RecalculateTopTenTest is also possible, but note a
mocked Scheduler accepts the same BukkitRunnable twice, so a naive test passes while
production throws.