Unify surrogate/no-surrogate mapping behind a single abstraction

## Context

PR #1578 adds a no-surrogate mode (`HYPERLIGHT_MAX_SURROGATES=0`) that uses `WHvMapGpaRange` instead of `WHvMapGpaRange2`. Currently `whp.rs` branches on `Option` to choose the mapping path.

## Proposal

Unify the surrogate and no-surrogate paths so `whp.rs` doesn't need to know or care which mode is active. Two possible approaches:

1. **Enum / trait abstraction**: Make `SurrogateProcess` an enum (or `dyn Trait`) with two variants — one backed by a real surrogate process (`WHvMapGpaRange2`) and one that maps from the host process directly (`WHvMapGpaRange`). The `NoSurrogateGuard` could be folded into the no-surrogate variant.

2. **Always use `WHvMapGpaRange2`**: Use the current process handle as the source when surrogates are disabled, eliminating the branch entirely. This needs validation — it's unclear whether `WHvMapGpaRange2` with `GetCurrentProcess()` is a supported pattern.

Either way, the mapping call would move into the surrogate module so `whp.rs` just calls a single `map(...)` method.

## Origin

Suggestion from @syntactically in [PR #1578 review](https://github.com/hyperlight-dev/hyperlight/pull/1578).

Start by reading the current surrogate handling in whp.rs and the surrogate module, then inspect PR #1578 and its review discussion. Define a single mapping abstraction covering both SurrogateProcess and no-surrogate mode, validate whether WHvMapGpaRange2 supports GetCurrentProcess(), and ensure whp.rs calls one map(...) method without mode-specific branching.

Written by the indexing model from the issue text.