Return null instead of panicking for allocations exceeding the buddy allocator's maximum order

Nobody has claimed this yet.

`SafeZoneAllocator` panics in the `LockedHeapWithRescue` callback when the requested power-of-two allocation size is at or above `1 << ORDER`:

```rust
if page_aligned_size.trailing_zeros() as usize >= ORDER {
unimplemented!("requested size {page_aligned_size:#} is too large");
}
```

This violates `GlobalAlloc::alloc`'s OOM contract and prevents fallible APIs such as `Vec::try_reserve` from returning `TryReserveError`. For example, with `HEAP_ORDER = 25`, a request for 32 MiB reaches this panic regardless of available memory and may abort because allocator panics cannot safely unwind.

Change the rescue callback to decline unsupported requests without panicking, allowing `LockedHeapWithRescue::alloc` to retry and return null.

## Acceptance criteria

- Over-`ORDER` allocations return null rather than panic.
- `Vec::try_reserve` or an equivalent fallible-allocation test returns `Err`.
- Existing supported buddy allocations and rescue-backed heap growth continue working.
- Tests cover both an unavailable-memory request and a request exceeding the configured maximum order.

Follow-up from #1219.

Start at the SafeZoneAllocator rescue callback and trace how LockedHeapWithRescue::alloc handles a declined request. Add coverage for unavailable-memory and over-ORDER allocations, including a fallible Vec allocation. Done means unsupported requests return null or a fallible allocation error without panicking, while supported buddy and rescue-backed allocations still work.

Written by the indexing model from the issue text.