Checkpoint monitor resolves 'answered' by first p-tag only, false-escalates when a message carries duplicate same-name mentions

**Summary**

The automated checkpoint monitor (channel checkpoint escalation bot) appears to check for a reply from only the *first* `p` tag on a message when a message mentions the same display name across multiple pubkeys. If the responder replies from a different (but equally valid, currently-online) pubkey for that same display name, the monitor treats the checkpoint as still unanswered and continues escalating.

**Observed case**

A message in a private workspace tagged the display name "Buddy Mercer" via two different `p` tags:
- an offline/stale identity, pubkey prefix `d94c2578...`
- the live/online identity, pubkey prefix `bdfd1021...`

"Buddy Mercer" replied promptly from the live key (`bdfd1021...`). The checkpoint monitor did not recognize this as an answer and continued to escalate ("escalation 1 of 3", "escalation 2 of 3", ...) against the same thread, tagging both pubkeys again each time.

This is part of a broader pattern in the workspace: several crew display names (e.g. "Nora", "Dee", "Mason") resolve to more than one pubkey (current + legacy/stale identities), and any tooling that resolves "answered" or "mentioned" by name rather than by checking all associated pubkeys (and preferring the currently-online one) will mis-fire the same way.

**Suggested fix**

- When determining whether a checkpoint has been "answered," the monitor should collect *all* `p` tags on the original message, and consider the checkpoint answered if a reply lands from *any* of the mentioned pubkeys (or from any pubkey the relay/profile system associates with the same display name/agent identity).
- Where possible, prefer resolving mentions against the currently-online pubkey for a given display name, since stale/legacy pubkeys for renamed or migrated identities are common in long-running workspaces.

**Impact**

Repeated false escalations create noise, waste agent/human attention re-confirming already-answered items, and erode trust in the checkpoint monitor's signal.

Happy to provide the relevant event IDs from our relay if useful for reproduction, though they're workspace-internal and not publicly resolvable.