feat: announce v1 homes waiting to be imported

[milanmalhotra]

Closes #54. Second of the five sub-issues split out of #41, and it sits on top of #53, which owns the top of onEnable.

What changed

An admin who upgrades from Set Homes v1 and reads nothing sees an empty homes list on first boot, while plugins/SetHomes/homes.yml sits there full of homes with nothing saying so. The first anyone hears of it is a player asking where their homes went.

Now, when v1 homes are present and our own database is empty:

• onEnable logs a WARNING block naming the file, how many homes are waiting, and the command to run.
• Anyone holding sh2.import-homes gets the same reminder in chat when they join, because plenty of admins never read the console.

Both stop for good the moment any home exists here. The condition is re-read every time, so there is no marker file and nothing to switch off after the import.

Auto-import on enable was the original proposal on #41 and was rejected there: the config half of the migration cannot be automated anyway, a silent import makes a dropped home impossible to surface, and plugin-managed worlds are not loaded at our onEnable. This is the replacement for what auto-import was really buying, which is that nobody discovers the problem from player complaints.

Notes for review

• PendingV1Import lives in importers/ so the knowledge of v1's file layout stays next to SetHomesV1Importer rather than being duplicated.
• waitingToBeImported() checks the database before touching disk, so a server that has already imported never reads v1's file, and the join path checks the permission before either, so an ordinary player's join costs nothing.
• Cadence is every join, not once per session. The condition clears itself the moment a home exists, so it cannot nag a migrated server, and an admin who joins during a busy moment still sees it next time.
• The count is entries in v1's file. The import may then report fewer, naming why: in the run below, 12 waiting, 11 imported, 1 skipped for a missing world. At startup we cannot know which worlds will resolve, so undercounting would be the wrong guess.
• v1ImportPending is documented in the migration section of the README rather than added to the ## Configuration table, which is explicitly the settings most servers change. A migration-only message override would misrepresent that table.
• support/PluginBoot is new, extracted because this is the second test class that has to arrange state before onEnable. SetHomesV1ClashTest keeps its own copy rather than widening this diff into merged code.

Verification

MockBukkit: 377 before, 385 after, Failures: 0, Errors: 0, Skipped: 0.

Three tests were watched failing before the code existed: the startup block, the unknownHomes count, and the join notice. The other five passed on first run, so the guards were broken four ways to prove them, each restored byte-identical:

Break	Test that caught it
permission check removed from PlayerJoin	aJoiningPlayerWithoutTheImportPermissionIsNotTold
countAll() > 0 early return removed	theNoticeStopsOnceAHomeExistsHere
waiting == 0 early return weakened	both nothingIsSaid... tests
a per-player "told once" set added	theNoticeRepeatsOnEveryJoin

One test needed a harness fix, diagnosed rather than guessed: MockBukkit drops a PermissionAttachment on disconnect(), so a rejoining player silently held no permissions. Production keeps no per-player state, so the test re-grants before the second join.

Verified on the local Paper 1.21.4 server against the real v1 data, both directions:

• v1 homes.yml present and our database empty: Set Homes found 12 home(s) in plugins/SetHomes/homes.yml at startup, and the chat line on join, seen again after a reconnect.
• import-homes sethomes confirm from the console: 11 imported, 1 skipped for the missing creative world.
• Restarted with homes present: silent in both places.

12 is the same total the migration rehearsal recorded for that file, reached here by a different code path.