[Fulminate] Fix range map

[ZippeyKeys12]

There are bugs that used to be detected, that are no longer flagged since 384f4f3.

I am not that familiar with the code or the data structure, so I asked Claude Code and it gave the report below.
This PR includes its implementation of the first "potential fix".

Claude Code's Report

Analysis: Why commit 384f4f3 broke bug detection

Root Cause: rmap_find_range ignores unmapped gaps

The commit replaced the byte-by-byte hash-table ownership tracking with a range-map (rmap). The new c_ownership_check has a fast path that short-circuits based on rmap_find_range, but that function silently ignores unmapped bytes.

The fast path in c_ownership_check (utils.c:507-517)

 rmap_range_res_t res = ownership_ghost_state_extrema(address, size);
 if (res.defined && res.min == res.max) {
     if (res.max == WILDCARD_DEPTH)      return FULL_WILDCARD;
     else if (res.max == expected_stack_depth) return NO_WILDCARD;  // <-- BUG
 }

Why rmap_find_range is misleading

In rmap.c, find_range returns res_empty for EMPTY nodes, and res_append skips empties:

// rmap.c:256 — EMPTY nodes contribute nothing to the result
case EMPTY:  return res_empty;

// rmap.c:33-38 — res_append skips empty results
static inline result_t res_append(const result_t *a, const result_t *b) {
    bool a_ok = !res_is_empty(a), b_ok = !res_is_empty(b);
    if (a_ok && b_ok) return (result_t){min(a,b), max(a,b)};
    return a_ok ? *a : (b_ok ? *b : res_empty);  // gaps silently dropped
}

So rmap_find_range(addr, addr+size-1) computes min/max only over bytes present in the rmap. Unmapped bytes are invisible.

The failure scenario

Consider a multi-byte access (e.g., CN_LOAD on a struct field) where:

• Some bytes in [addr, addr+size-1] are owned at expected_stack_depth
• Some bytes are not in the rmap at all (unmapped / not owned)

1. rmap_find_range returns {defined=true, min=D, max=D} (only sees mapped bytes)
2. Fast path matches: res.min == res.max == expected_stack_depth
3. Returns NO_WILDCARD — skips the byte-by-byte loop that would catch the unmapped bytes
4. cn_failure is never called — ownership violation goes undetected

Before the commit (correct behavior)

CN_LOAD looped byte-by-byte, calling c_ownership_check for each individual byte:

for (int __tmp_i = 0; __tmp_i < sizeof(typeof(LV)); __tmp_i++) {
    c_ownership_check("Load", (uintptr_t)__tmp + __tmp_i, get_cn_stack_depth());
}

Each byte was checked against the hash table individually. An unmapped byte returned NULL from ht_get, yielding UNMAPPED_VAL, which != expected_stack_depth, triggering cn_failure.

Confirmation approach (using --print-seed / --seed)

To confirm:

1. Build CN at commit 384f4f3bf^ (parent), run with --print-seed
2. Capture a seed that finds the bug.
3. Build CN at commit 384f4f3bf, run with --seed=<captured_seed>
4. Observe the bug is no longer detected with the same input.
5. Optionally add fprintf(stderr, ...) in c_ownership_check at the fast-path return to confirm it fires where the old code would have called cn_failure.

Potential fix

The fast path needs to verify that the entire range is mapped before trusting the min/max. Options:

1. Add rmap_is_fully_covered(k0, k1, map) — returns true only if every byte in the range has an entry. Use this as a precondition for the fast path.
2. Remove the fast path — always run the byte-by-byte loop. Correct but slower.
3. Change rmap_find_range semantics — return defined=false when the range has gaps. But this would break cn_postcondition_leak_check and cn_loop_leak_check, which intentionally scan the full address space and want to ignore gaps.