do_bsys_alloc() does not zero its allocations; dboot's do_mem_alloc() did.

What changed

Under dboot, do_mem_alloc() memset every allocation it returned. The Limine
adapter path does not: do_bsys_alloc() (uts/i86pc/os/fakebop.c) contains no
bzero/memset at all, so BOP scratch is handed out holding whatever the
previous occupant left.

Status: correctness, NOT a defect hunt

This was suspected during the 4-CPU boot investigation and measured not to be
the cause (p=1.00, recorded in the design doc's do-not-re-run list). Do not
re-open it as a boot-failure theory.

It is still a contract that was silently dropped in the dboot deletion, and
callers written against the old behaviour would not fail loudly. Worth
restoring on correctness grounds, cheaply.

Note

limine_mem.c's own hb_alloc() does zero every allocation, deliberately.
The inconsistency between the two boot-time allocators is itself a trap.

Fixed in rev 345 (ee3c758de9b9).

do_bsys_alloc() now bzero()s what it returns, restoring the contract dboot's
do_mem_alloc() had and the dboot deletion dropped silently. The zero happens
after both mapping loops, so every page is mapped when it runs.

Deliberately unchanged: this is a correctness restoration, and the note in the
issue still stands — it was measured not to be the 4-CPU boot bug (p=1.00).
Do not re-open it as one.

Verified on a full build of tip: boot matrix 28/28 (1 vCPU 4/4, 2 vCPU 12/12,
4 vCPU 12/12), 17 daemons / 0 failed every boot, pool ONLINE, DTrace and mdb -k
both working. No measurable boot-time cost.