fix: update hardcoded osy-version from 5.0 to 5.5 in AddCase.js

[lil-aditya]

Closes #453

Summary

• What changed: "osy-version": "5.0" → "osy-version": "5.5" on line 232 of AddCase.js
• Why: The version was not updated after the v5.5 sync. Every new model gets stamped "5.0" while the app displays "ver.5.5"

Impact

1. Version mismatch: UI header says v5.5, saved genData.json says 5.0
2. Export/import: UploadRoute.py reads osy-version to decide migration paths — wrong stamp = wrong handling
3. Future compat: Any v5.5-specific logic keyed on osy-version won't fire for these models

Proof

And UI header shows "MUIO ver.5.5"

Existing related work reviewed

• Reviewed all 24 open PRs — none touch the osy-version assignment in AddCase.js

Scope check

• No unrelated refactors
• Implemented from a feature branch
• Change is deliverable without upstream 'OSeMOSYS/MuIO' dependency
• Base repo/branch is 'EAPD-DRB/MUIOGO:main' (not upstream)

[Copilot]

Pull request overview

Updates the osy-version value stamped into newly created model genData.json payloads so the stored metadata matches the app’s reported version.

Changes:

• Update hardcoded "osy-version" in AddCase.js from "5.0" to "5.5" for new model saves.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Changing the stamped osy-version to 5.5 will cause exported models to be rejected on re-import: API/Routes/Upload/UploadRoute.py only recognizes versions up to '5.0' (handle_full_zip checks name == '5.0' and otherwise returns an error). Either keep osy-version aligned to the data-format version that the backend accepts, or update the upload validation/migration logic to accept '5.5' (and treat it equivalently to '5.0' if the format is unchanged).

Suggested change

	"osy-version": "5.5",
	"osy-version": "5.0",

[lil-aditya]

@SeaCelo I’d appreciate it if you could review this.