fix(krea2): hold Raw's schedule shift at the end of its fit

[Pfannkuchensack]

Summary

Krea-2 Raw sets its noise schedule shift (mu) from the image's token count, along a line through 256 tokens → 0.5 and 6400 tokens (1280×1280 of area) → 1.15. Above 6400 tokens the line kept climbing, and nothing held it. Turbo uses a fixed 1.15 and is not affected.

Raw image	mu before	mu after	28-step schedule before
1024²	0.91	0.91	—
1536²	1.45	1.15	—
2048²	2.21	1.15	about half the steps above sigma 0.9
4096²	7.41	1.15	every step above sigma 0.98

calculate_shift now holds mu at the end of its fit, as the FLUX.1, Z-Image and LTX-2 fits already do. The hold follows a checkpoint's own scheduler_config.json.

Why now: an img2img pass enters krea2_denoise on a step of this schedule. At 4096² no step is anywhere near a mid-range sigma, so an img2img or upscale pass at that size replaces the image instead of refining it. The Upscale widget for Krea-2 (follow-up PR) depends on this.

Elsewhere:

• ComfyUI samples every Krea-2 model at a constant mu of 1.15 (supported_models.py, Krea2.sampling_settings). That is the value this PR holds at.
• diffusers 0.41 Krea2Pipeline extrapolates like the old code.

The node goes from 1.3.0 to 1.3.1; its inputs are unchanged. The shift field description now says where the hold starts.

Related Issues / Discussions

Same fix as the Z-Image shift hold (31c476f). Needed by the Krea-2 Upscale widget PR, which follows once this is merged.

QA Instructions

Automated

• pytest tests/app/invocations/test_krea2_denoise.py: 79 passed.
  • New: the curve is checked on calculate_shift against literal values, including a non-square 2048×768 frame (6144 tokens, below the hold).
  • New: a custom scheduler fit ending at 1024 tokens holds at its own max_shift, run through _run_diffusion.
  • Removing the hold fails 17 tests across this file and the Upscale contract test.
• ruff@0.11.2 check / format --check: pass. openapi.json and schema.ts are regenerated; only the field description and the version change.

Raw text-to-image A/B (RTX 4090, Raw Q4_K_M GGUF, 28 steps, CFG 5.5, one warm-up, held and old mu interleaved per seed; old mu passed through shift):

Size	Seeds	Result	Time per image
1536² (mu 1.45 → 1.15)	1234, 99, 7	Near-identical for 1234 and 99; seed 7 changes a side building and text	2:42 vs 2:45
2048² (mu 2.21 → 1.15)	1234, 99, 7	Same subject; the layout may change for a seed; held mu draws finer stone and railing detail, old mu smoother surfaces	~5:10 both

No image shows doubled subjects or a broken composition.

Img2img at large sizes (through the Upscale widget of the follow-up PR, Raw Q4, Balanced): a 1024² source at 4× (4096²) keeps composition, lettering and rock structure in 8:46 min. Without the hold the pass would enter at sigma 0.98.

Review

Findings resolved:

• The hold moved from the invocation into calculate_shift, where the other fits keep theirs.
• A comment claimed that keys missing from a scheduler_config.json fall back to Krea-2's defaults. They take diffusers' scheduler defaults; the comment now says so.
• The docs give the limit as an area (about 1.6 MP), not a side length, and say how to override it.

Remaining: the low end still extrapolates below 256 tokens, as the FLUX.1 and Z-Image fits do; at 64² mu is 0.475.

Compatibility / Rollout

• Same seed, different image: Raw images larger than 1280×1280 of area (6400 tokens) no longer reproduce with the same seed. Image metadata does not record mu, so recalling an older large Raw image renders it on the new schedule. To get the old schedule back, set Shift on Denoise - Krea-2 in a workflow to the old mu.
• Turbo, Raw at or below 1280×1280 of area, and any explicit shift are unchanged.
• Saved workflows: the 1.3.1 node has the same fields. The editor offers to update 1.3.0 nodes; running them is not blocked.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Meaningful regression coverage added / updated where needed; obsolete tests/code removed
• Persisted-state and API changes include required migrations / compatibility validation
• Relevant performance/efficiency opportunities considered; material claims have evidence
• Material review findings resolved and relevant checks rerun
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}