Add Firestore vector value binding

[AdamEssenmacher]

Summary

• Add the Firebase CloudFirestore FIRVectorValue binding.
• Add FieldValue.VectorWithArray(NSNumber[]) for the native vectorWithArray: selector.
• Add a targeted local E2E runtime-drift case that exercises the selector and verifies the returned vector array can be read.

Validation

• dotnet pack source/Firebase/CloudFirestore/CloudFirestore.csproj --configuration Release --output output
• tools/e2e/run-firebase-foundation.sh --package-dir output --configuration Debug --runtime-drift-case cloudfirestore-fieldvalue-vectorwitharray
• tools/e2e/run-firebase-foundation.sh --package-dir output --configuration Debug
• git diff --check

Notes

• The binding shape is taken from the Firebase 12.6 xcframework headers: + (FIRVectorValue *)vectorWithArray:(NSArray<NSNumber *> *)array, FIRVectorValue.array, and initWithArray:.
• This PR is scoped to the Firestore vector value missing binding only.

[Kapusch]

Hi there! I noticed your recent PRs mention running E2E tests with run-firebase-foundation.sh for validation. Shouldn't we mention this in the main CONTRIBUTING.md / main README.md docs? (cf: https://github.com/AdamEssenmacher/GoogleApisForiOSComponents/tree/main/tests/E2E/Firebase.Foundation)

Also, if that's the new mandatory process, should we add a comment to the other #109 , to ensure it follows the new expectations?

[AdamEssenmacher]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[AdamEssenmacher]

Hey @Kapusch. Good question, and happy to add some context.

The bindings in this repo have always been a bit of a moving target. They’re incomplete, and in some cases incorrect, which can lead to runtime failures. That’s been true even back in the Xamarin/Microsoft days. Updates were mostly reactive, and there’s been ongoing drift as the native Firebase APIs evolve.

Since taking over, I’ve mostly continued that approach (fix what’s needed, add APIs on demand), mainly because there hasn’t been any real automated validation in place. A full audit just wasn’t practical before.

Recently though, I started experimenting with a more systematic approach using Codex + updated tooling. I had it generate a drift audit (~400 potential issues), filter to likely runtime problems, and then build an E2E harness to actually prove failures in the simulator. From there it’s been a loop of fix → validate → repeat. I'm in the early stages of letting it prove itself / trusting it.

⸻

Re: your question

The run-firebase-foundation.sh E2E setup is part of that experiment. It’s not a formal/required contributor workflow yet. t’s still evolving pretty quickly. (I'm in the red -> green phase of red -> green -> refactor)

I do think we’ll want to document it in CONTRIBUTING once things settle, but I’d rather not lock it in prematurely.

⸻

Re: #109

I don’t think we need to enforce this retroactively yet, but I’ll likely start encouraging it for new PRs once the workflow stabilizes. Also #109 is unfortunately not entirely correct. I'd like to get a few of these low-hanging, high-impact fixes in and then the plan is to release 12.6 -> 12.12 (or current) incrementally very soon.

⸻

Big picture, this is heading toward a more repeatable “detect → prove → fix” loop, which should make the project a lot more reliable over time, and less costly to maintain.