fix(metadata): harden discriminator heuristics, iTXt chunks, scalar fallback

[lstein]

Two real fragility items, plus a small adjacent cleanup

The "defensive int/float coercion in `InvokeMetadataView`" item the reviewer also flagged turned out to be a non-issue — see "intentionally not changed" below.

1. `GenerationMetadataAdapter` discriminator heuristics

For pre-discriminator payloads (no `metadata_version` key), the adapter has to infer the schema version. The previous logic had three real issues:

Issue	Effect
`canvas_v2_metadata` checked before `app_version`	A v3 image that happened to carry `canvas_v2_metadata` was forced to v5
`v3.` prefix not handled (only `3.`)	InvokeAI's own v\ -prefixed builds fell into the catch-all "future = v5" branch
Four nested branches	Hard to reason about

Refactored into a `_infer_metadata_version` staticmethod with a clear priority:

1. `app_version` if present (authoritative — accept both bare and `v`-prefixed for v1/v2 and v3, route 4.x+ to v5).
2. Structural fingerprints (`canvas_v2_metadata` → v5, `model_weights` → v2).
3. Default to v3.

Seven unit tests cover the heuristic in isolation (no full schema construction needed — the heuristic just picks a version, doesn't validate).

2. PNG `iTXt` / `zTXt` chunks in `metadata_extraction.py`

Pillow returns different shapes for the three PNG text-chunk types:

Chunk	Pillow returns
`tEXt`	`str`
`zTXt`	`str` (decompressed) in recent Pillow, `bytes` historically
`iTXt`	`(text, lang, translated_keyword)` tuple in some versions

Without normalization, an `iTXt` chunk handed `json.loads` a tuple (TypeError on the next line) and the entire metadata block was silently lost — the image rendered with the EXIF fallback or nothing at all.

Adds `_normalize_text_chunk` that funnels tuple → first-element, bytes → utf-8, then `str(...)`. The three JSON extractors all flow through it. Adjacent cleanups in the same file:

• `except (json.JSONDecodeError, Exception)` (the broader class subsumes the narrower) → just `Exception`.
• Four `print("Warning: ...")` calls → `logger.warning(...)` so they respect log configuration.

3. Scalar-table fallback for unparseable payloads

`invoke_formatter` used to render an opaque `"Unknown invoke metadata format"` placeholder when the discriminated union rejected a payload (unknown future `metadata_version`, malformed shape, etc.). Now it extracts whatever top-level scalar fields are present and renders them via the existing `_scalar_table` — the user still sees the seed / model / prompt etc. The placeholder remains for payloads with zero scalar fields.

Intentionally not changed

The original review item on `int(self.seed)` / `float(lora.weight)` in the view turned out to be moot: the Pydantic schemas declare these as `int` and `float` respectively, which the v2 validator strict-rejects non-numeric strings against at parse time. By the time the view sees a value, it's already coerced. Adding defensive `try/except` would be unreachable code, so I left those call sites alone.

Test plan

• `ruff check` — clean
• `pytest tests/backend` — 275 passed (was 256; 19 new tests across the three areas)
• Manual: open the metadata drawer on a v3 image (re-test that the discriminator fix didn't regress v3 detection)
• Manual: open the drawer on an image with iTXt-encoded `invokeai_metadata` (e.g. one written by certain third-party tools that compress the chunk); confirm metadata renders instead of the EXIF fallback
• Manual: open a synthetic image with `metadata_version: 999`; confirm the drawer shows the top-level scalar fields instead of "Unknown invoke metadata format"

Net +235 lines across 5 files; 88 of those are the new tests.

🤖 Generated with Claude Code