`vm_range` is lossy on 32-bit platforms reading 64-bit objects

Nobody has claimed this yet.

The current implementations of `SectionHeader::vm_range` and `ProgramHeader::vm_range` look like this:

```rust
/// Returns this section header's virtual memory range
pub fn vm_range(&self) -> Range {
self.sh_addr as usize..(self.sh_addr as usize).saturating_add(self.sh_size as usize)
}
```

Those `as usize` casts are silent truncating casts on 32-bit platforms when the input object is 64 bit. This also means the `saturating_add` is subtly wrong, since it will saturate to the current host's `usize::MAX` rather than the actual end of section in the file. The return type of `vm_range` probably ought to be `Range` to match the size of `sh_addr`/`sh_size` and friends, or be a `Result`/`Option` to indicate cases where the offset/size in the file are not representable in the host `usize` type.

Start with the implementations of SectionHeader::vm_range and ProgramHeader::vm_range, then inspect their callers to understand the expected range type and error behavior. Check the behavior when 64-bit object values are read on 32-bit platforms; done means the API no longer silently loses address or size information and its tests cover the affected cases.

Written by the indexing model from the issue text.