feat: add batch consume to the source Hopper and adapters

[joshua-temple]

What this change does

Adds batch consume to the source Hopper and adapters (one of the four roadmap items from #131). A BatchHandler (func(ctx, []Message) []Result) plus a WithBatch(size, maxWait) option lets a consumer process many messages per call instead of one.

The engine accumulates up to size messages per ordered lane, or until maxWait elapses on an injected clock, invokes the BatchHandler once, then settles each message by its positionally-aligned Result. Per-key ordering and the MaxInFlight bound are preserved; a result-count mismatch terms the unmatched messages as poison (ErrBatchResultCount), and a decode failure is isolated to its own message.

When a subscription advertises the Batched capability the engine hands it whole fetched batches and regroups by key; otherwise it falls back to per-message accumulation. Kafka exposes its polled records and JetStream its pull fetch through Batched. Batch is opt-in — per-message stays the default.

Why

Sinks, stores, and downstream APIs are often far more efficient per call when fed in batches, but doing that by hand breaks per-key ordering and the in-flight bound. Folding batching into the Hopper keeps those invariants intact while letting throughput-sensitive consumers opt in with one option.

Relates to: follows up the source Tier-1 PR (#131).

Checklist

• Commits are signed off (git commit -s) per the DCO
• Conventional commit messages (type: subject)
• Tests added (table-driven memsource tests, Example, and a fuzz test asserting no loss/dup/reorder within a key); core at 92.1% coverage
• Public API documented (godoc + Example + concurrency docs page)
• mage check runs in CI across the workspace and the GOWORK=off source destinations