flow.google.com: image i2i --ref <uuid> of an image already in the target project is refused (exit 36) instead of referenced in place #995

Summary

On an account served by flow.google.com (#639), gflow image i2i --ref <media-uuid> is refused with exit 36 ("a reference given by Flow media UUID") even when the referenced image was generated by gflow in the same project the i2i targets (--project <id>), and the local catalog knows both its project and its Flow caption.

The only way to reuse such an image is to pass its local file, which uploads it again. On an account that has not accepted Flow's one-time upload-terms dialog, that upload fails (exit 27, MediaUploadRejectedError), so a purely-generated pipeline (t2i → i2i) is blocked by an upload it does not actually need.

Use case

A two-step pipeline with a human review step in between, so the steps are separate gflow invocations:

1. gflow image t2i "<character sheet>" --project P --json → images[0].media_name = U (catalog row: flow_project_id = P, metadata_json.display_name = <Flow caption>).
2. Later: gflow image i2i "<scene with that character>" --ref U --project P --json.

Step 2 is refused on flow.google.com. Within a single invocation the same thing already works (#913, "ref": "batch:N" in gflow run), so the gap is only that an image from an earlier invocation never gets in_project=True.

Evidence (develop @ c4b47a7)

• api/transports/migrated_composer.py _unported_image_form:

  if any(not ref.in_project for ref in request.refs):
      # Only an image this run generated in this project is referenced in place (#913);
      # a UUID ref from the catalog or MCP is not ported here.
      return "a reference given by Flow media UUID"

• ImageRef.in_project is only set by image_batch.py (batch:N), FlowApiClient.upload_reference and the ui_automation upload path, i.e. only for images produced in the current process.
• cli_image._enrich_uuid_refs already looks the UUID up in the catalog and copies display_name (+ local file), but it does not look at asset.flow_project_id, so a catalogued image of the very project being driven still arrives with in_project=False.
• The in-place machinery itself is not run-scoped: reference_existing → await_existing_references checks the image's tile is in this page's project grid (img[data-media-id=<uuid>], reloading on a miss) and attach_existing_references selects it in the @ picker by caption + /asb/<token>, then _image_body_problem checks the submit carries exactly those ids. An image that is not really in the project still fails loud (ReferenceNotFoundError), it is never dropped.

Proposal

Mark a catalog UUID ref in_project=True when the catalog records it in the same Flow project the generation targets, on both surfaces:

• CLI: _enrich_uuid_refs(refs, profile, project_id=<resolved project>).
• MCP/worker: _ref_meta_entry also carries flow_project_id; worker.codec.build_image_request sets in_project when it equals the payload's project_id.

No transport change: the migrated driver's existing guards (caption must be searchable, tile must be in this project's grid, exact submit ids) still apply. A ref without a recorded caption (e.g. GFLOW_CLI_HISTORY_PROMPTS=redacted) or from another project keeps today's exit 36.

Out of scope here (possible follow-up): video i2v start/end frames by UUID on flow.google.com (_unported_form), which would remove the remaining upload in a t2i → i2v flow.

I'm opening a PR for the proposal.