feat(core): the client running a job is available from its context

[giraffesyo]

From the API review of hopper's two real users.

The seam. Workers are registered before the client that runs them exists, and a component that both registers workers and needs the client, to insert follow-up jobs from a subscriber or a worker, has nowhere to get it. One user resolves this with a Bind(client) step after construction and a nil check in every handler; the other has not hit it yet because its only job is a no-op.

The change.

• hopper.ClientFromContext[TTx](ctx) returns the client running the job whose context this is, and false outside a job or for another transaction type. execute puts the client in the job context next to the output holder, so workers and subscribers (which run as jobs) both get it.
• hopper.ContextWithClient(ctx, client) builds such a context, for tests that call a worker inline with hoppertest.Work.
• hoppertest.Start(ctx, t, client) starts a client and stops it at test end with a context that outlives the test's, which both users' tests wrote by hand.

Tests. A worker and a subscriber insert follow-ups through the context's client; a plain context and a mismatched transaction type return false; hoppertest.Work with and without ContextWithClient. Full suite passes locally with -race; lint clean.

Considered and left out. A Config.MaxWorkers shortcut for the default queue: both users write the one-entry Queues map, but a second way to say the same thing is not worth it.

PLAN.md §4.1 and the README describe the accessor. No SQL or hot-path change, so no benchmark.