Handle AXI write strobes in axi_to_ahb

## Problem

`src/integration/rtl/axi_to_ahb.sv` stores each AXI `WSTRB` value in `w_beat_strb`, but never uses it when issuing the corresponding AHB write. The four AXI paths exposed by `ip_xxx_3511_hs_mem_compound_wrapper.sv` therefore acknowledge sparse writes while the downstream target updates lanes selected only by `AWSIZE` and the address.

This can corrupt bytes whose write strobes were low. An all-zero strobe can also cause an unintended write.

Originally reported in PR #18: https://github.com/chipsalliance/usb2/pull/18#discussion_r3994164485

## Expected behavior

- Preserve AXI write-strobe semantics for every write beat.
- Do not perform a downstream write for an all-zero strobe beat.
- Fully support valid strobes for packet-memory targets, or document and enforce a narrower supported profile.
- Reject unsupported strobe and size combinations with an AXI error and no target side effects.
- Do not use generic read-modify-write for side-effecting CSR registers.

## Acceptance criteria

- Add directed tests for full, sparse, and all-zero `WSTRB` values.
- Verify byte, halfword, and word accesses at each supported lane alignment.
- Verify rejected combinations return an error and leave CSR and memory contents unchanged.

Start in src/integration/rtl/axi_to_ahb.sv by tracing w_beat_strb from capture through the corresponding AHB write, then inspect the four AXI paths in ip_xxx_3511_hs_mem_compound_wrapper.sv. Use the acceptance criteria to define directed tests for full, sparse, and zero strobes across byte, halfword, and word alignments; done means valid writes preserve lanes, unsupported combinations error without side effects, and CSR writes avoid generic read-modify-write.

Written by the indexing model from the issue text.