Add a contact-first command to change the default delivery box

Start by reading the existing CLI code for screener approve --box, including how box names are resolved. Then trace the SDK's Designations().Create(boxID, contactID) and Contacts().Screen(contactID, status) primitives. Done means a contact-first command can route a contact to the supported boxes without requiring a clearance ID, with structured output matching existing mutation conventions.

Problem

HEY's web UI lets you open a contact and change Deliver their emails to… directly between Imbox, The Feed, Paper Trail, and Screened Out.

The CLI does not currently expose the same contact-first workflow. The closest route is clearance-oriented:

1. Find the contact or search hey screener history.
2. Extract the contact's clearance ID.
3. Run hey screener approve <clearance-id> --box "The Feed".

That is cumbersome for both people and agents, and requires callers to understand the distinction between contact IDs and clearance IDs for what is conceptually a contact preference.

Proposed behavior

Add a dedicated contact command that mirrors the web UI, for example:

hey contact deliver <contact-id> --to "The Feed"
hey contact deliver <contact-id> --to "Paper Trail"
hey contact deliver <contact-id> --to "Imbox"
hey contact deliver <contact-id> --to "Screened Out"

The exact command name could also be route, designate, or an extension to contact update. It would be especially useful if the target could be resolved by contact ID or email address.

Implementation context

The SDK already exposes contact/box primitives that appear intended for this workflow:

• Designations().Create(boxID, contactID) designates a contact to a box.
• Contacts().Screen(contactID, status) updates screening status by contact ID.
• Box names can already be resolved by existing CLI code used by screener approve --box.

A dedicated command could resolve the destination internally and avoid leaking clearance IDs into the user-facing workflow. Returning the contact, destination, and reverse command in structured output would also fit the CLI's existing mutation conventions.

Expected outcome

An agent should be able to translate “send future mail from this contact to The Feed” into one direct command, matching the web UI's contact-level action without first searching Screener history.