Guest-debug gdbstub omits shared linear memories from the synthetic address space

### Reproduction

Wasmtime's built-in guest-debug gdbstub does not expose a shared linear memory in its synthetic address space. This prevents LLDB from reading globals and runtime-backed values even though source breakpoints, Wasm locals, and backtraces work.

`main.wat`:

```wat
(module
(memory (export "memory") 1 1 shared)
(func $entry (export "_start")
i32.const 0
i32.const 42
i32.store
unreachable))
```

Build and start guest debugging:

```sh
wat2wasm --debug-names --enable-threads main.wat -o main.wasm
wasmtime run -g 1234 -W threads=y,shared-memory=y main.wasm
```

Using a Wasm-aware LLDB:

```text
(lldb) target create main.wasm
(lldb) process connect --plugin wasm connect://127.0.0.1:1234
(lldb) continue
# stopped at the final `unreachable`, after storing 42
(lldb) process plugin packet send qXfer:memory-map:read::0,ffff
response: ...
(lldb) memory read --size 4 --format decimal --count 1 0x0
error: memory read failed for 0x0
```

The equivalent unshared memory is reported as a `ram` region at address 0 and can be read successfully.

### Expected result

The shared memory should appear in the RSP memory map and support reads while the guest is stopped, just like an unshared memory. Guest source-language adapters need this to inspect globals and runtime values.

### Likely cause

`Instance::debug_memory` intentionally returns only unshared `Memory` and directs callers to `debug_shared_memory` for shared memory:

https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/wasmtime/src/runtime/debug.rs#L202-L247

However, the debugger host API's `instance_get_memory` only calls `debug_memory`:

https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/debugger/src/host/opaque.rs#L166-L173

The gdbstub address-space implementation consequently has no shared-memory resource to enumerate:

https://github.com/bytecodealliance/wasmtime/blob/v47.0.3/crates/gdbstub-component/src/addr.rs#L60-L78

It looks like the debugger resource abstraction needs to represent both `Memory` and `SharedMemory`, then implement size/read/write operations for both.

### Environment

- Wasmtime 47.0.3 (`5554cc1a6`, 2026-07-31); the same behavior was also observed with 44.0.0
- wasi-sdk 33 LLDB 22.1.0 with the Wasm process plugin
- macOS arm64

This was found while implementing WASI source debugging for xgo-dev/llgo#2164, but the WAT reproduction is independent of LLGo.