directory: member resolve matches id prefixes after label tiers; member search skips IME composition

[irisfeng]

Problem

Member resolution (GET /v1/directory/resolve, used by agents for mention ids and by the web member picker) only ever tried label (display-name) matching. An id like carol@acme.com could not be resolved by typing carol@acm — the natural prefix form — because ids were only reachable via a full exact match.

Fix

Exact-id and label-exact matching stay first; the fuzzy tiers become, in order: label-prefix → label-contains → id-prefix → id-contains. The id tiers only widen resolution for queries where no label matches at all, so:

• a surname that label-contains several people stays ambiguous (the disambiguation safety net consumers rely on) instead of collapsing onto one id-prefix hit,
• channel resolution keeps label-only matching — channel-id prefixes are noise.

The web member-picker input skips IME composition events and searches on compositionend, so CJK input methods fire one search per committed candidate instead of one per pinyin keystroke. Chrome dispatches the committing input with isComposing: true and no trailing non-composing input, so the compositionend handler is load-bearing, not redundant.

Tests

• id substring resolves every matching member; a unique email local-part prefix resolves to one
• label-contains matches stay ahead of a lone id-prefix hit (the ambiguity-preservation case)
• channel resolution does not fall back to channel-id prefixes when no name matches

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}