peerDependencies pin @mittwald/react-use-promise to ^2.6.0, which cannot be satisfied with its 4.x release

The published packages declare a @mittwald/react-use-promise peer range that
cannot be satisfied alongside its current release, so any project combining them
with @mittwald/flow-react-components gets a peer-range warning on install.

At 4.449.0, three published packages declare:

"peerDependencies": { "@mittwald/react-use-promise": "^2.6.0" }

• @mittwald/api-models
• @mittwald/api-client-commons
• @mittwald/api-client

@mittwald/react-use-promise is at 4.2.2. The highest version ^2.6.0
admits is 2.9.9, and @mittwald/flow-react-components requires ^4.2.2 in
both dependencies and peerDependencies — so the two ranges are disjoint:

^2.6.0 ∩ ^4.2.2  →  no intersection
semver.satisfies("4.2.2", "^2.6.0")  →  false

Yarn reports the non-overlapping ranges during install of a project that uses
both.

Why this has gone unnoticed

@mittwald/react-use-promise is optional: true in peerDependenciesMeta, so
this is a warning rather than an install failure. Nothing breaks — it is noise
that every consumer of both libraries sees and has to decide to ignore.

Is the range deliberate?

Possibly not: 3.0.0 and 4.0.0 of react-use-promise were React-19 majors
("React 19", then "switched to React 19 (only)"), not API rewrites of the hooks
these packages use. That reads like a range that was never widened rather than a
constraint someone chose. The devDependencies entry sits at ^2.6.2, which
fits that reading.

If there is a reason to hold it — something in useSuspense/usePromise that
changed, or a deliberate React 18 floor — that is worth writing down, because
from the outside it looks like an oversight.

Suggested fix

Widen the peer range to cover the current majors, e.g.

"peerDependencies": { "@mittwald/react-use-promise": "^2.6.0 || ^3.0.0 || ^4.0.0" }

in all three packages, and bump the devDependencies entry so CI actually
exercises the version consumers install.

Found while upgrading a project that uses both @mittwald/flow-react-components
and @mittwald/api-client. Verified against the npm registry and master at the
time of writing; happy to open a PR if the widened range is what you want.