Mixing roaring bitmaps with different copy_on_write flag values is unsafe

See the following example. Four bitmaps are created. Copy on write is enabled for all of them, except the second. Then, the union of the bitmaps is computed in the order (((bm1 | bm2) | bm3) bm4) (the order seems to be important for the bug).

When doing the last union, a supposedly unreachable false assertion is triggered. The type of one container (after unwrapping) is not defined.

void test_multiple_union() {
    roaring_bitmap_t *bm1 = roaring_bitmap_from_range(172033, 172034, 1);
    bm1->copy_on_write = 1;
    roaring_bitmap_t *bm2 = roaring_bitmap_from_range(247243, 447339, 1);
    bm2->copy_on_write = 0;
    roaring_bitmap_t *bm3 = roaring_bitmap_from_range(23705, 95255, 1);
    bm3->copy_on_write = 1;
    roaring_bitmap_t *bm4 = roaring_bitmap_from_range(163739, 393874, 1);
    bm4->copy_on_write = 1;

    roaring_bitmap_t *tmp1 = roaring_bitmap_or(bm1, bm2);
    roaring_bitmap_t *tmp2 = roaring_bitmap_or(tmp1, bm3);
    roaring_bitmap_t *result = roaring_bitmap_or(tmp2, bm4); // ← fails here

    roaring_bitmap_free(bm1);
    roaring_bitmap_free(bm2);
    roaring_bitmap_free(bm3);
    roaring_bitmap_free(bm4);
    roaring_bitmap_free(tmp1);
    roaring_bitmap_free(tmp2);
    roaring_bitmap_free(result);
}

Start by running the test_multiple_union reproduction and trace the final roaring_bitmap_or call into include/roaring/containers.h around the false assertion at line 1027. Compare container handling as copy_on_write changes across the intermediate unions; done means the reproduction no longer triggers the assertion and bitmap union behavior remains correct.