Expand migrated image API: model selection, edits and 2K export

[Bl0ck154]

Summary

Expands the migrated flow.google.com image path with the capabilities currently exposed by Flow's UI, fixes Nano Banana Pro transport/count semantics, adds bounded wave-based recovery for transient image failures, and restores true image edit + high-resolution export.

What changes

• expose explicit image_model selection on POST /api/flow/generate-image
• add HARBOR_SEAL (Nano Banana 2 Lite) alongside Nano Banana Pro / Nano Banana 2
• pass syntactically valid future Flow image wire ids through unchanged
• expose count (1-4) and optional seed
• implement count=N like Flow itself: N independent single-image ogiZ0b RPCs, each with its own single-use reCAPTCHA
• mirror Flow's captured x4 launch cadence (~0.0 / 0.5 / 1.5 / 2.5 seconds) instead of bursting every variant simultaneously
• serialize Enterprise reCAPTCHA minting in the page bridge
• include WIZ source-path and page locale metadata; GEM_PIX_2 requires this even where Lite is tolerant
• wait for the entire first image wave to settle before retrying transient image RPC [8]
• retry only [8], once, after a 34-second cooldown with fresh request UUIDs and the same seed
• preserve successful variants after a final partial failure and return complete=false, generated_count, and failed_variants
• accept all five current image ratios: 1:1, 9:16, 16:9, 3:4, 4:3
• use the current IMAGE_ASPECT_RATIO_PORTRAIT_THREE_FOUR spelling while retaining the old alias
• fix /api/flow/edit-image: source media uses Flow's BASE_IMAGE wire type (2), extra refs remain REFERENCE type (1)
• port image high-resolution download through SPrCad / FlowService.UpsampleImage
• add POST /api/flow/export-image (2k default, 4k plan-gated)

Live verification

Verified end-to-end against the current Flow frontend/account:

• Nano Banana 2 Lite generated successfully, including count=4
• Nano Banana 2 generated successfully
• Nano Banana Pro direct generation works once source-path matches the UI
• live CDP capture proved Flow x4 uses four independent ogiZ0b requests, not one multi-item RPC
• Nano Banana Pro x4 using the captured UI cadence returned 4/4 images in 57.4s wall-clock
• final combined wave implementation Nano Banana Pro x2 returned 2/2, complete=true, in 63.37s
• a short 6-second retry was still rejected under load, motivating the longer bounded cooldown
• Nano Banana Pro generated a real BASE_IMAGE edit successfully
• SPrCad 2K export produced a valid JPEG; 1376x768 source -> 2752x1536 (~3.1 MB)

The current Flow UI exposes exactly five image aspect ratios: 1:1, 9:16, 16:9, 3:4, 4:3.

The [8] retry is explicitly a FlowKit resilience policy. Live UI capture did not show the same automatic retry after a failed x4 wave.

Forward compatibility

Flow can add model ids independently of FlowKit releases. Previously an unknown model was silently replaced with GEM_PIX_2; this PR only falls back for blank/invalid ids, while a valid Flow-style wire id is preserved as requested.

Validation

• 108 focused Flow/image tests passed
• MV3 cold-start bootstrap test passes
• OpenAPI schema confirms image_model, count, seed, reference_media_ids, and /api/flow/export-image
• git diff --check clean

The repository's full test run on upstream ce37f4b still has the same unrelated pre-existing failures around processor._retry_state and result_handler fixtures (3 failed, 250 passed, 9 errors); the focused migrated Flow/image tests are green.

[crisng95]

@Bl0ck154 thank for your commits, but it has some conflict, help me fix them I will review it today

[Bl0ck154]

Rebased this PR onto the current main and resolved the conflicts while preserving the newer upstream Flow/video changes. The branch is now mergeable/clean on GitHub.\n\nValidation after the rebase:\n- focused Flow/image tests: 110 passed\n- git diff --check: clean\n- Python compile checks: passed\n- node --check for the touched extension scripts: passed\n\nI also cross-checked the server checkout before resolving this: its tracked main was already fully pushed (HEAD == origin/main), so there were no unpublished code changes there to recover.