fix + feat: Model Ultra Necrozma's transformation, and let form conditions name their base form

[MiquelRForgeFlow]

Change description

Ultra Necrozma couldn't be represented properly: it's a battle-only form that can only be reached from Dusk Mane or Dawn Wings, but pokemon_form_conditions had no way to say which form a transformation starts from.

This PR:

1. Trigger Ultra Necrozma with the held Ultranecrozium Z using the existing held-item trigger (same pattern as Mega stones).
2. Add a nullable base_form FK to PokemonFormCondition, so a battle-only form change can name the sibling form(s) it transforms from. Exposed on a form's trigger_conditions (REST) and as a base_form relationship (GraphQL). Nullable, so existing conditions are unaffected.
3. Populate base_form wherever the base is a specific, unambiguous sibling rather than the default form: Ultra Necrozma (← Dusk Mane / Dawn Wings), Ash Greninja (← Battle Bond), Complete Zygarde (← 10% / 50% Power Construct), (Galarian) Zen Darmanitan, Meowstic / Tatsugiri / Magearna megas, Toxtricity / Urshifu Gmax, and Mimikyu Busted.

Battle forms that transform from their default/any form (Mega Charizard, most Gigantamax, Alcremie, Pyroar, Floette…) are intentionally left null.

Out of scope: Minior's forms are modelled inconsistently (is_battle_only flags + condition placement) and need a separate cleanup PR; not touched here.

AI coding assistance disclosure

I used AI to determine which files needed to be touched, and to check if new code is coherent.

Contributor check list

• I have written a description of the contribution and explained its motivation.
• I have written tests for my code changes (if applicable).
• I have read and understood the AI Assisted Contribution guidelines.
• I will own this change in production, and I am prepared to fix any bugs caused by my code change.

[MiquelRForgeFlow]

@Naramsim

[MiquelRForgeFlow]

By the way, the battle-only thing is the only assured fact. I can make that fix a part. And leave the ultra-burst-item vs held-item for discussion.

[jemarq04]

It should probably just be held-item specifying the Ultranecrozium Z I think. Though finding a way to specify the required base form to specify Dawn/Dusk form is something we can consider going forward

[MiquelRForgeFlow]

I can make that fix a part

Done in #1619.

Though finding a way to specify the required base form to specify Dawn/Dusk form is something we can consider going forward

Fine by me, let's think how to do it. Probably a new column in some place. Any suggestion?

[MiquelRForgeFlow]

Following up on the base-form question

Though finding a way to specify the required base form to specify Dawn/Dusk form is something we can consider going forward.

I'd like to propose a minimal way to cover this now, since it's the missing piece for Ultra Necrozma (and several other in-battle form changes).

The problem. pokemon_form_conditions already records how a battle-only form is triggered (here: held ultranecrozium-z), but not which sibling form it transforms from. Ultra Necrozma is special because it can only be reached from Dusk Mane or Dawn Wings (not from base Necrozma) so a single implicit "base = default form" assumption doesn't hold, and there can be more than one base.

Proposal. Add a nullable base_form_id column to pokemon_form_conditions (FK to Pokemon, mirroring how pokemon_evolution already stores base_form_id/evolved_form_id inline). It stays NULL for the common case where the base is the default/implicit form (Mega, Gmax, Primal…), so the change is fully additive and every existing row is untouched.

For Ultra Necrozma this becomes two rows (same held-item trigger, one per base form):

pokemon_form_id,form_trigger_id,trigger_item_id,trigger_ability_id,trigger_move_id,base_form_id
10316,1,969,,,10155   # necrozma-ultra ← necrozma-dusk-mane
10316,1,969,,,10156   # necrozma-ultra ← necrozma-dawn-wings

The API would surface it under the existing trigger_conditions on the form (as a base_form summary object, like base_form on evolution details), so no new endpoint is needed.

Why a column rather than a new table. It's the same pattern pokemon_evolution already uses for base_form_id, and the surface area is small: one nullable FK, a migration, one field in the PokemonFormCondition build loader, and one field in PokemonFormConditionSerializer.

Broader value. This isn't just Necrozma; it lets consumers stop heuristically guessing the base form for other in-battle changes, e.g.:

• Zygarde Complete ← 10%/50% Power Construct
• Greninja Ash ← Battle Bond
• Darmanitan Zen ← Standard, Galarian Zen ← Galarian Standard

One open question: base_form_id → Pokemon keeps it consistent with pokemon_evolution.base_form (that's why the example uses pokémon IDs 10155/10156), but it does mean this row mixes a pokemon_form id with a pokemon id. Happy to point it at PokemonForm instead if you'd prefer intra-table consistency.

If this direction sounds good, I'll add the column, migration, loader, serializer field, and the Necrozma rows in this PR.

[MiquelRForgeFlow]

Hello, this PR is ready. I implemented the per review proposal. It contains a migration script.

One open question: base_form_id → Pokemon keeps it consistent with pokemon_evolution.base_form (that's why the example uses pokémon IDs 10155/10156), but it does mean this row mixes a pokemon_form id with a pokemon id. Happy to point it at PokemonForm instead if you'd prefer intra-table consistency.

I pointed it to PokemonForm, it was making more sense. Also I populate base_form wherever the base is a specific, unambiguous sibling rather than the default form, except the Minior case. Minior's forms are modelled inconsistently (is_battle_only flags + condition placement) and need a separate cleanup PR after this one.