LocalMessageService should tolerate malformed POP offset metadata

## Problem

`LocalMessageService.popMessage(...)` assumes that broker POP response metadata is internally consistent when `startOffsetInfo` is present:

```java
int index = sortMap.get(key).indexOf(messageExt.getQueueOffset());
Long msgQueueOffset = msgOffsetInfo.get(key).get(index);
...
ExtraInfoUtil.buildExtraInfo(startOffsetInfo.get(key), ...)
```

If `msgOffsetInfo` is missing, does not contain the key, has fewer offsets than the decoded messages, or `sortMap` cannot find the message offset, Proxy can throw `NullPointerException` or `IndexOutOfBoundsException` while translating the local broker response.

## Expected behavior

Proxy should treat incomplete POP offset metadata as an invalid message entry, log a useful message summary, skip that entry, and keep processing the rest of the response instead of failing the whole local POP request.

## Scope

Track 2 / Proxy runtime diagnostics and POP robustness. This only adds defensive handling for malformed broker POP metadata in local mode and should not change valid POP response handling.

## Evidence

- `proxy/src/main/java/org/apache/rocketmq/proxy/service/message/LocalMessageService.java`
- The code dereferences `sortMap.get(key)`, `msgOffsetInfo.get(key)`, and `startOffsetInfo.get(key)` without checking missing keys or invalid indexes.

Start in proxy/src/main/java/org/apache/rocketmq/proxy/service/message/LocalMessageService.java at LocalMessageService.popMessage(...), tracing how sortMap, msgOffsetInfo, and startOffsetInfo are used for each decoded message. Verify behavior for missing keys, short offset lists, and absent queue offsets; malformed entries should be logged and skipped while valid entries continue processing without changing valid POP responses.

Written by the indexing model from the issue text.