vmem: make SpaceReferenceMapping per-arch and fold space_aware_map dispatch

Follow-up to review feedback on #1385. Bundling four related items into one issue because they form a single coherent change to the multi-space page-table walker interface and splitting them would produce awkward half-states.

## Proposed changes

**Move `SpaceReferenceMapping` into each arch module.** Right now the struct lives in `hyperlight_common::vmem`, but it is only ever produced by `arch::walk_va_spaces` and consumed by `arch::space_aware_map` — the common module never touches it. Pulling it per-arch lets each architecture pick the representation that best fits its walker, and lets architectures that never emit `AnotherSpace` (amd64 today) use `Void` so the match arm in `space_aware_map` is statically unreachable via `match impossible {}` instead of today's `unreachable!` branch. Reviewer comment: https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132166982 and https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132207257.

**Replace the `depth: usize` field with an arch-specific enum.** On i686 the only valid depth is 1 (the leaf PT). On amd64 it would be one of `{ Pdpt, Pd, Pt }`. A per-arch enum makes invalid depths unrepresentable and removes a class of off-by-one bugs. Reviewer comment: https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132168766.

**Change \`our_va\` / \`their_va\` from \"start of the aliased region\" to \"any address in the aliased region\".** Treating the fields as \"must be in the region\" rather than \"must be the start\" eliminates a failure mode in `space_aware_map` where a caller passes an unaligned address and the call silently produces a wrong link. Combined with the per-arch enum it lets every value of `SpaceReferenceMapping` have a well-defined semantic interpretation. Reviewer comment: https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132174870.

**Make \`space_aware_map\` take \`SpaceAwareMapping\` and dispatch internally.** Today the caller in `Snapshot::new` pattern-matches on `SpaceAwareMapping` and dispatches to either `vmem::map` (for `ThisSpace`) or `vmem::space_aware_map` (for `AnotherSpace`). Moving that dispatch inside the API — so callers hand the `SpaceAwareMapping` straight in and let the arch module route it — is more consistent with how `walk_va_spaces` already returns the enum, and it ties naturally into the per-arch typing change above. Reviewer comment: https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132196047.

## Why bundle

Each change is small on its own but they share the same data shape (`SpaceReferenceMapping` and its fields). Landing them together means the walker/map API moves in one atomic step; doing them as four scattered patches would produce intermediate commits where the type lives in one place but the caller still dispatches externally, or the field semantics are partly updated. The whole cluster lives inside `hyperlight_common::vmem` + its arch modules and does not touch `hyperlight_host` at all.

## Acceptance

- `SpaceReferenceMapping` defined in each arch module; on archs that never emit `AnotherSpace`, it is `Void`.
- `depth` replaced by an arch-specific enum.
- Doc invariant and implementations updated to accept any address in the aliased region.
- `space_aware_map` takes `SpaceAwareMapping`; the caller in `Snapshot::new` becomes a straight `for sam in mappings { unsafe { vmem::space_aware_map(&pt_buf, sam, &built_roots) } }`.
- i686 and amd64 both compile; existing snapshot unit tests still pass.

## Links

- PR #1385 threads this rolls up: [r3132166982](https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132166982), [r3132168766](https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132168766), [r3132174870](https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132174870), [r3132196047](https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132196047), [r3132207257](https://github.com/hyperlight-dev/hyperlight/pull/1385#discussion_r3132207257).