go-arc was verify-only: Verify was the entire exported surface, yet ARC
is fundamentally about a forwarder sealing a message. The sealing logic
existed in rest-mail's pipeline but was not exported from the library.

Add arc.Seal, the counterpart to Verify: it adds one ARC set (AAR, AMS,
AS) for instance i=N and returns the message with it prepended, ready to
relay. cv= is computed by verifying the chain being extended (none with
no prior chain, else the pass/fail Verify reports), so what Seal produces
Verify accepts. It reuses go-dkim's canonicalization/signing primitives
and the very ARC-Seal base builder the verifier uses, guaranteeing
byte-for-byte sign/verify parity over the transmitted bytes.

- seal.go: Seal, SealOptions, SealResult (rsa-sha256; relaxed default).
- seal_test.go: hermetic in-memory key/resolver round trips — single-set
  seal->verify (pass, i=1), two-hop reseal (pass, 2 sets, cv=pass),
  tampered-body failure, broken-incoming-chain cv=fail, option guards.
- ExampleSeal + README/godoc: document sealing, drop verify-only framing.

Verify is unchanged.

Closes #4