Add deck URL loading for Moxfield and Archidekt

[Madwand99]

Summary

Adds a new “Provide Deck URL” option to the deck chooser, allowing users to load decklists directly from supported deckbuilding sites. This initial implementation supports Moxfield and Archidekt URLs.

Loaded URL decks are saved under the user deck directory in decks/URL, include source URL metadata, and can be selected/reloaded later from the deck chooser.

Details

• Added Provide Deck URL as a deck source option.
• Added a URL input row with reload support and Enter-to-load behavior.
• Implemented Moxfield deck loading through the Moxfield API.
• Implemented Archidekt deck loading through Archidekt deck JSON endpoints.
• Resolves cards by name, set code, and collector number where available.
• Handles split/MDFC card names by falling back to the front face when needed.
• Saves deck metadata for:
  • Deck Type
  • Source URL
• Syncs the URL field when selecting previously loaded URL decks.
• Persists URL-loaded decks on disk.
• Added localization keys for the new UI and loader errors.

[MostCromulent]

You might not be aware but there's already another deck URL importer PR here: #10247

[Madwand99]

Nope, I didn't know. Oh well, maybe this one has some useful ideas.

[Madwand99]

Comparison with #10247

I also looked at the similar work in #10247. That PR takes a different but related approach: it adds URL fetching to the Deck Import dialog and converts supported remote decklists into plain import text. This branch instead adds URL loading as a first-class Deck chooser source, builds Deck objects directly, persists them under decks/URL, stores source URL metadata, and supports selecting/reloading previously loaded URL decks.

Both approaches have useful ideas, but they serve slightly different workflows.

What this branch does well

• Integrates URL decks directly into the Deck chooser flow.
• Saves loaded decks on disk so they behave like previously loaded decks.
• Stores Source URL metadata and syncs it back into the URL field when selecting a saved URL deck.
• Stores deck format metadata where available.
• Resolves cards directly into Forge PaperCard objects, using set code and collector number when available.
• Handles split/MDFC names by falling back to the front face when needed.
• Uses structured JSON parsing instead of regex/string parsing for Moxfield and Archidekt payloads.
• Includes localized UI and error strings.

Useful ideas from #10247

• It introduces a provider/fetcher structure with one class per site. That would be a good direction if this branch later grows beyond Moxfield and Archidekt.
• It includes support for additional sites such as EDHREC, TappedOut, and MTGGoldfish, which gives us a useful roadmap.
• It documents some provider limitations, especially that TappedOut and MTGGoldfish exports may not reliably preserve Commander/Sideboard sections. If we add those later, we should surface that limitation clearly to users.
• It uses api2.moxfield.com; our current Moxfield endpoint works in testing, but a fallback endpoint could be a future robustness improvement.

Suggested future direction

If we add a third or fourth provider, we should consider refactoring DeckUrlLoader into provider-specific loader classes, while keeping this branch’s direct Deck construction, metadata persistence, URL reload behavior, and structured parsing model. That would combine the clean extensibility of #10247 with the stronger Deck chooser integration implemented here.

[MostCromulent]

@Madwand99 some thoughts after testing both this and #10247 (bearing in mind I'm not a dev, but I do almost exclusively use desktop and have an interest in the UI flow):

• In concept URL import is a useful feature, clearly there is user demand for it.

• Whatever approach is taken to implementation will need to grapple with Jetz' comment here.

• I don't like that the URL importer function itself (not just the imported decks) are accessed through a new category dropdown in the deck selection menu, rather than being integrated into the existing deck editor / deck import flow. That is non-intuitive and creates two parallel deck creation streams. This should definitely be avoided.

• For that reason I think the core UI implementation in the other PR is preferable: URL import is found directly in the deck importer, where I would expect to find it. This also makes the import results obvious to the user so they can edit or fix import errors before creating deck etc.

• What I think this PR adds which might potentially be useful is the ability to link a deck to a specific URL, and then refresh the deck contents to pick up any external changes on a deck building website. I think the preferable way for that to be implemented is that once a deck is created there is some button in the deck editor UI ("Refresh from URL" or similar) which re-opens the deck importer and causes a fresh import to occur based off the saved URL.

(@Jetz72 FYI)

[Madwand99]

Yes, I'm aware of the comment. It is a good one.

I, in turn, find the idea of loading an existing deck using the deck editor very counter-intuitive. URL decks are "net decks", why shouldn't they be loadable where other net decks are loaded? Of course, I wouldn't mind if the loading were available in both locations, and simply used a common URL loading back-end.