Write property-based tests with Hypothesis for a function with a large input space

Write property-based tests using Hypothesis for the function below, instead of (or alongside) example-based tests. The goal is to find inputs that break an invariant nobody thought to write a manual test case for — that's the entire reason to reach for Hypothesis over a hand-picked example.

FUNCTION UNDER TEST
def merge_intervals(intervals: list[tuple[int, int]]) -> list[tuple[int, int]]: merges overlapping (start, end) intervals.

KNOWN INVARIANTS
The merged output covers exactly the same total range as the input; no two intervals in the output overlap; the output is sorted by start.

INPUT DOMAIN CONSTRAINTS
Each interval has start <= end; the list can be empty; intervals can be given in any order, not just sorted.

SUSPECTED WEAK SPOT
Intervals that touch exactly at a boundary (one ends where the next begins) — unclear if the current code treats that as overlapping or not.

REQUIREMENTS
1. Design a Hypothesis strategy (st.integers(), st.text(), st.builds(...), or a composed strategy) that actually respects Each interval has start <= end; the list can be empty; intervals can be given in any order, not just sorted. — a strategy too loose generates inputs the function was never meant to handle and produces false-failure noise; a strategy too narrow misses the real edge cases Hypothesis exists to find. State why the chosen strategy matches the real domain.
2. State each property being tested as an invariant that should hold for every valid input, not as "the output equals this specific value" — a property test asserting a hardcoded expected output for one specific generated input isn't testing a property, it's a disguised (and fragile) example test. Cover at least: The merged output covers exactly the same total range as the input; no two intervals in the output overlap; the output is sorted by start., plus any property implied by the function's own contract (e.g. a sort function's output should always be the same length as its input and contain the same elements).
3. Specifically target Intervals that touch exactly at a boundary (one ends where the next begins) — unclear if the current code treats that as overlapping or not. with a strategy that's more likely to generate inputs near that boundary, using st.integers(min_value=..., max_value=...) or filters/mapping to bias generation toward the suspicious region rather than relying on uniform random luck to eventually hit it.
4. Use assume() to discard genuinely invalid generated inputs rather than writing a strategy so constrained it never explores the boundary of what's valid, and explain the difference between the two approaches for this specific case.
5. If Hypothesis finds a failing example, don't just report the raw random-looking input — explain what property it violates and why that specific shape of input is the minimal case Hypothesis's shrinking found, since that minimal case is usually the one that actually explains the bug.
6. Use @settings(max_examples=...) deliberately rather than accepting the library default everywhere — a property with a small, well-bounded input space needs far fewer generated examples to be exhausted than one with a large or unbounded space, and running the default example count uniformly wastes time on simple properties while sometimes under-exploring genuinely large ones.

OUTPUT FORMAT
1. The Hypothesis strategies used, with a one-line justification each.
2. The property test functions.
3. If you can identify a case that would actually fail with the current implementation, show it and explain the violated invariant — don't just assert the tests would pass without checking.
4. Any @settings override applied and why the default example count wasn't the right fit here.