Allow party invitations to be retried and expire them consistently (#368)

[sfedev]

Fixes #368

What was wrong

An invitation that the server rejects, for example because the recipient already belongs to another party, still disabled the sender's invite button. Even after the recipient left that party, the sender had to leave and recreate their own party to invite them again.

Example: A leads a party, B has their own. A invites B and the server rejects it. B leaves their party. Before this change, A's invite button stays disabled and A must leave and recreate the party to invite B. After it, A can invite B again after a short cooldown and B can accept.

Underneath there were three server-side inconsistencies as well: invitation cleanup iterated a PartyComponent entity view that is never populated (player invitations live in Player::m_party), invitations were keyed by Player*, and acceptance did not check the deadline.

What changes

• UI (player-list.service.ts, group.service.ts, client.service.ts, typings.d.ts, new models/party-invite.ts, mock): per-player invite state with a short retry cooldown instead of a permanent flag; incoming invitations expire using the remaining time reported by the native client; invitations are cleared on join, leave and disconnect; a rejected acceptance keeps other valid invitations.
• Native client (PartyService.cpp): forwards the remaining time to the overlay, drops invitations that are already expired or arrive while in a party, validates the deadline on accept, and clears invitations on join and party teardown.
• Server (PartyComponent.h, PartyService.cpp/.h): invitations keyed by player id; cleanup walks the player manager; TryConsumeInvitation checks the deadline on accept and consumes the invitation once; RevokeInvitations removes a player's outgoing invitations when they disconnect or stop leading a party.
• Tests: four server component tests (Code/tests/server/party_invitations.cpp) behind a TPServerTests target enabled by the server_tests xmake option (off by default), and the party browser tests extended to ten cases.

No new network messages or opcodes. The TPServerTests harness is the same one #891 adds for its object tests, minus the object sources; whichever PR lands second will be rebased on it.

How it was checked

• SkyrimTogetherServer, SkyrimTogetherClient, TPTests and TPServerTests (117 assertions in 4 cases) build and pass on this branch.
• Angular production build passes. The ten party browser tests pass against a dev server of this branch (run with a newer Playwright than the pinned one because the pinned Chromium does not start on the test machine; the spec body is unchanged).
• In game with two local clients: the blocked re-invite was reproduced on the previous build, and on a playtest build carrying this change B left their party and accepted a new invitation from A without A recreating the party. The expiry and other lifecycle edge cases are covered by the automated tests but were not all exercised in Skyrim.

An earlier attempt at this issue, #371, was closed without merging in 2023. This PR is limited to invitations.