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

## 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 --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:

```console
hey contact deliver --to "The Feed"
hey contact deliver --to "Paper Trail"
hey contact deliver --to "Imbox"
hey contact deliver --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.

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.

Written by the indexing model from the issue text.