feat(guild): separate scout invitations into guild_invites table

Scout invitations were stored in guild_applications with type 'invited',
forcing the scout list response to use charID as the invitation ID — a
known hack that made CancelGuildScout semantically incorrect.

Introduce a dedicated guild_invites table (migration 0012) with a serial
PK. The scout list now returns real invite IDs and actual InvitedAt
timestamps. CancelGuildScout cancels by PK. AcceptInvite and DeclineInvite
operate on guild_invites while player-applied applications remain in
guild_applications unchanged.

server/migrations/sql/0012_guild_invites.sql

@@ -0,0 +1,23 @@
+BEGIN;
+
+-- Dedicated table for guild-initiated scout invitations, separate from
+-- player-initiated applications. This gives each invitation a real serial PK
+-- so the client's InvitationID field can map to an actual database row
+-- instead of being aliased to the character ID.
+CREATE TABLE guild_invites (
+    id           serial PRIMARY KEY,
+    guild_id     integer REFERENCES guilds(id),
+    character_id integer REFERENCES characters(id),
+    actor_id     integer REFERENCES characters(id),
+    created_at   timestamptz NOT NULL DEFAULT now()
+);
+
+-- Migrate any existing scout invitations from guild_applications.
+INSERT INTO guild_invites (guild_id, character_id, actor_id, created_at)
+SELECT guild_id, character_id, actor_id, COALESCE(created_at, now())
+FROM guild_applications
+WHERE application_type = 'invited';
+
+DELETE FROM guild_applications WHERE application_type = 'invited';
+
+COMMIT;