[Task] Review FV `new_from_address()` safety invariants

VolumeRef::new_from_address() and FirmwareVolume::new_from_address() are unsafe fn functions whose safety contracts are difficult for callers to satisfy correctly.

Callers must guarantee the backing memory is valid for fv_length bytes, but fv_length is not known until the function reads it from untrusted memory at base_address. The API only accepts an address and not an independently trusted size so callers have no way to supply a bound even when they have one. As a result, the function passes an untrusted fv_length to slice::from_raw_parts(), and the internal validation in new() is defeated because the buffer was created from the same value being checked.

https://github.com/OpenDevicePartnership/patina/blob/b059896152fbccac29662e7cfcab946bd1afc8d4/sdk/patina_ffs/src/volume.rs#L203-L244

As unsafe fn functions, they require that the caller must ensure this address is valid for N bytes, but the contract only works if the caller can actually know N. In this instance, the new_from_address function takes base_address then reads fv_length from the memory at that address and uses it immediately. Whether the contract can lead to real Undefined Behavior depends on whether callers can independently bound the memory region. Some callers do this, for example Firmware Volume HOBS have both base_address and length fields.

This issue tracks reviewing the safety conditions and interface/documentation to determine if there is a clearer and safer way to have the size be passed.

Read sdk/patina_ffs/src/volume.rs at the implementations of VolumeRef::new_from_address() and FirmwareVolume::new_from_address(), then inspect callers such as Firmware Volume HOB handling, which provides both an address and length. Review whether the safety contracts and interface give callers an independently trusted bound; done means the safety conditions and resulting API or documentation are clearly established.