Add order-based party roster, back-navigation in battle selection, fix win-state cutscene leak

- Battle selection menu can now go back a fighter to re-decide their move,
  and battle win/loss no longer leaks the round's remaining queued move
  cutscenes into the ending state (cutsceneSystemDiscardQueued).
- Party roster is now driven by party.jsonc: every defined member always
  exists (partyInit), while party->order alone determines who's currently
  active - partyAddMember/partyRemoveMember (and their cutscene items) now
  activate/deactivate an existing roster member by index instead of
  creating/destroying one, with removal compacting order to stay packed.
- New PARTY_ADD_MEMBER/PARTY_REMOVE_MEMBER/PARTY_HEAL_MEMBER/PARTY_HEAL_ALL
  cutscene items.
- saveSlotInit/partyInit now return errorret_t and take their target
  struct directly (saveslot_t*/party_t*) instead of implicitly operating
  on SAVE.slot; saveSlotReadJSON resets through saveSlotInit rather than
  duplicating the reset logic.
- Test coverage: stub the JSON asset loader in save test fixtures so
  partyInit's real party.jsonc load runs against an in-memory doc instead
  of hanging with no asset system initialized.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

assets/party.jsonc

@@ -0,0 +1,13 @@
+{
+  // Starting party roster, loaded by partyInit into a fresh save slot.
+  "members": [
+    {
+      "attack": 10, "defense": 5, "magic": 0, "speed": 10, "luck": 0,
+      "healthMax": 30, "mpMax": 10
+    },
+    {
+      "attack": 8, "defense": 6, "magic": 4, "speed": 8, "luck": 1,
+      "healthMax": 25, "mpMax": 15
+    }
+  ]
+}