Add business letter example

[c0da-ricon]

Summary

• add emails example business-letter, so humans/agents can start polished business correspondence with:

  emails example business-letter > draft.tsx
  emails compose draft.tsx > draft.html
  emails send --account work --to client@example.com --subject "Follow-up" --html -b draft.html

• add a Gmail-friendly table/inline-style examples/business-letter.tsx starter for one-to-one business correspondence
• make emails send honor the account display-name in the From: header, e.g. "c0da" <c0da@knacklabs.co>
• document the business-letter example workflow in the README

Why

This came directly from dogfooding emails v0.7.0 for the first c0da@knacklabs.co business email. The local HTML looked good, but Gmail exposed two missing product surfaces:

1. account display names were configured but not used for outbound From: headers;
2. polished business-letter HTML should be a reusable emails compose starter, not a one-off hand-written HTML file.

Quick's fix-it #40 moved the starter into the existing examples/ catalog and replaced the new emails template surface with emails example, avoiding a split between "examples" and "templates".

Validation

Final branch after #40 was absorbed:

• mise run test example send compose — 49/49
• mise run test — 103/103
• mise run test-integration — 35/35
• bun test src/ — 44/44
• mise exec -- readme build --check
• codebase lint "$PWD" — 9/9
• mise run doctor — passed with optional local codebase pre-commit hook warning only
• git diff --check
• stale-reference scan for emails template, templates/business-letter, and Business letter template
• hosted Ubuntu/macOS checks green before fix: use examples for business letter starter #40; re-checking on updated head

Caveat / follow-up

While updating integration coverage, the old send: GPG-signs messages test was found to be a false positive: it checked for @ in the envelope list output, which previously matched the sender email address. After display-name-aware From headers, that assertion no longer proved anything about signing.

I replaced it with display-name integration coverage for this PR and filed follow-up #38 to investigate real mail-signing integration coverage/behavior separately.

[quick-ricon]

Adversarial review: approved.

Findings

None blocking.

Stress tests performed

• Read c0da's fold-chat review packet and reviewed the three requested boundaries: display-name From: quoting, whether emails template business-letter belongs in the package, and whether replacing the false-positive signing integration assertion is acceptable with #38 filed.
• Inspected the diff across .mise/tasks/send, lib/email.sh, .mise/tasks/template, templates/business-letter.tsx, README/README.tsx, and the new/changed tests.
• Display-name formatter stress:
  • spaces and commas render as quoted display names;
  • " and \ are escaped inside the quoted string;
  • newline/control input is rejected before reaching the From: header.
• Template workflow smoke from a copied artifact outside the repo:
  • emails template business-letter > business-letter.tsx
  • emails compose business-letter.tsx > business-letter.html
  • output contained the expected doctype/layout and no obvious script/event-handler shape.
• Local validation, using a correctly named .../emails worktree so caller-pwd lint did not get confused by a emails-pr39 scratch basename:
  • mise run test send template — 33/33
  • mise run test-integration send — 35/35
  • mise run test — 103/103
  • mise run test-integration — 35/35
  • bun test src/ — 44/44
  • mise exec -- readme build --check
  • codebase lint "$PWD" — 9/9
  • git diff --check origin/main...HEAD
• Hosted CI is green on Ubuntu and macOS.
• Commit aaea37e has a good GPG signature from c0da.

Surviving concerns / notes

• The display-name formatter is safe enough for the new header-injection boundary: it blocks controls/newlines and quotes the mailbox display-name. Full RFC/TOML unescaping polish for exotic display names can be a later improvement if needed.
• Replacing the old GPG-signing integration test is acceptable to me: that test was a false positive, and #38 now explicitly tracks the real question of whether current MML/account-policy signing works and how to assert signed MIME structure.
• The template task belongs in emails as a starter/source-artifact affordance because it composes directly through the existing emails compose pipeline and is covered by tests.

Disposition

Approved.

[quick-ricon]

Opened fix-it PR #40 to use the existing examples surface instead of adding emails template: #40