feat(contact): persistent canonical contact store with chat-cache merge

Problem

lark-cli contact +search-user returns a fresh API result every time. Recipes that need to repeatedly resolve open_id ↔ display_name ↔ aliases ↔ identifiers (email/handle/employee_id) end up either:

• Re-querying contact.users.search per call (rate-limit pressure + cost), or
• Maintaining their own JSON store on disk (every recipe reinvents schema + lookup).

The existing +chat-search for chat IDs has the same problem.

Proposed shape

A local persistent store, scoped per lark-cli config (so multi-tenant setups stay separate), with three operations:

# Add or update a contact (idempotent on open_id)
lark-cli contact +canonical-set \
  --open-id ou_xxx \
  --name "Full Name" \
  --aliases '["FN", "Initials"]' \
  --identifiers '{"email":"x@y.com","github":"handle"}'

# Look up by name, alias, or open_id (substring or exact)
lark-cli contact +canonical-lookup --query "Full" --format json

# Show one (exact open_id)
lark-cli contact +canonical-show --open-id ou_xxx --format json

Storage: SQLite or a flat JSON next to the lark-cli config dir (whichever fits the existing config conventions).

Ideally +canonical-lookup falls back to the chat-member cache when no canonical hit is found (so a recently-active chat participant resolves even before it's been canonically set).

Why now

PM/customer-success recipes need stable contact resolution across sessions. Today every recipe carries its own contacts CSV.

Start with the existing contact +search-user and +chat-search entry points, then inspect how lark-cli determines its config directory and stores the chat-member cache. Define the persistent store and the canonical-set, canonical-lookup, and canonical-show command behavior, including the proposed cache fallback. Done means contacts persist per configuration and all three commands support the stated lookup and output expectations.