fix(schematics): emit AgentPlatformBackend from the v21 AI migration

[armando-navarro]

Fixes #3758

What changes

ng update now rewrites getVertexAI(...) to getAI(..., { backend: new AgentPlatformBackend() })
instead of the deprecated VertexAIBackend.

A call that passed a location option keeps it, carried into the new class's constructor. A call that
passed none, or a falsy one, moves from us-central1 to global, because the two classes default
differently.

What the migration warns about

The migration prints one warning for each file whose location changed, and a separate one where a
location is an expression only runtime can resolve.

Firebase does not serve the Live API models from global. When the workspace calls
getLiveGenerativeModel or startAudioConversation anywhere, the warning says so and stops
recommending a specific location, because that developer is choosing one rather than restoring the one
they had.

Evidence

Measured against a live project, two calls a few minutes apart differing only in the backend class:
gemini-3.7-flash returned 404 from us-central1 and 200 from global.

The migration was also run end to end through the real CLI against two applications, a fresh ng new
workspace and a copy of an existing app that had already been converted by hand. In the second case the
migration's output matched the hand-written version, and both applications built afterwards.

Merge order, red CI, and Tests

This must land after #3761, which raises the declared firebase minimum in src/schematics/common.ts and src/package.json.

Five schematics specs fail here, and they are the expected signal rather than a defect.

• The migration now emits AgentPlatformBackend, which @firebase/ai first shipped in 2.14.0 and firebase first bundled in 12.17.0, while this repo still declares ^12.4.0.
• One spec compares the emitted class against the declared minimum and fails deliberately until it rises.
• The other four compile the migration's output against the installed SDK and cannot resolve the class yet.
• Every other spec passes, and Build and Test chrome-headless are green.

To review this against a tree where those five pass, pull #3761 in first:

    gh pr checkout 3762
    git fetch origin pull/3761/head:pr-3761
    git merge pr-3761
    npm ci
    npm run build:jasmine && npm run test:node

The npm ci matters: #3761 moves the lockfile to firebase 12.18.0, and the four compile specs type-check against whatever is installed.

Reviewing the diff on its own needs none of that. The change is confined to the v21 migration and its specs, plus the upgrade guide.

[tyler-reitz]

Approving, and the region default is a deliberate call I'm fine with: Firebase recommends global, Gemini 3.x is only there, and the upgrade guide plus the per-file warning carry it. Worth watching for data-residency reports after release.

Ran it with #3761 merged: 244 specs, 0 failures, so the red CI here is the merge-order artifact you describe rather than a defect. Checked the parts only runtime settles: new VertexAIBackend() gives us-central1, new AgentPlatformBackend() gives global, and both guard with if (location), so an empty string really does fall to each default and the 'certain' classification is right. AgentPlatformBackend is absent from @firebase/ai 2.13.1 and present in 2.14.0, which firebase 12.17.0 bundles, so BACKEND_CLASS_FIREBASE_FLOOR is exact.

Neutering the region record turns 10 specs red while the "does not warn" ones stay green, so those specs are pointed at the right thing.

I didn't reproduce the gemini-3.7-flash 404/200 measurement, that one stays yours.

Merge order: this needs #3761 (now approved) in first. The suite does gate merging here, via the Branch protection aggregator job, so this can't land until the rebase turns it green.

[tyler-reitz]

Correction to my review above. I said the suite gates merging here and that this can't land until the rebase turns it green. Both are wrong, and the truth is worth knowing.

Branch protection is one of the two required contexts, but it's an aggregator job: needs: ['test', 'contribute', 'browser'] with a body of run: true. When one of those needs fails the aggregator isn't failed, it's skipped, and GitHub counts a skipped required check as satisfied. So right now this PR reads mergeStateStatus: UNSTABLE, mergeable: MERGEABLE with 12 red jobs. #3759 read BLOCKED before approval and CLEAN after, so the approval is the only real gate.

So please don't merge this before rebasing onto #3761, because nothing will stop you.

Probably worth its own issue: giving that job if: always() and asserting the needs' results would close the hole for every PR, not just this one.