Public way to supply the client to `JobCompleteTx` when completing in a different client’s transaction type

[pckilgore]

We run two clients against one database, and JobCompleteTx currently can’t be used cleanly in that topology without importing rivertest into production code.

Setup. Our application transactions come from a database/sql-based ORM pool, so transactional job inserts and JobCompleteTx must run on a Client[*sql.Tx] (riverprodatabasesql — we’re a Pro customer).

But a database/sql driver can’t LISTEN, which means remote cancellation of running jobs never reaches workers. The fix was to split: keep the *sql.Tx client for inserts/completion, and run workers on a riverpropgxv5 client so producers get a notifier. This seems like it will work well. The cancel’s pg_notify is emitted by the SQL itself, so any client can send and the pgx workers receive.

Problem. JobCompleteTx[TDriver] resolves its client with ClientFromContext[TTx](ctx). Inside a worker running under the pgx client, the context carries a *Client[pgx.Tx], so the *sql.Tx-typed lookup fails, even though we have a perfectly good *sql.Tx client to complete through.

The only public way to fix the context is rivertest.WorkContext.

// production code today:
ctx = rivertest.WorkContext(ctx, sqlTxClient)
_, err := river.JobCompleteTx[*riverprodatabasesql.Driver](ctx, tx, job)

Ask

Either of these would remove the rivertest import from production code:

1. Export the context setter (e.g. river.WithClient[TTx](ctx, client)), or
2. A JobCompleteTx variant that accepts the client explicitly, e.g. client.JobCompleteTx(ctx, tx, job) or river.JobCompleteTxClient(ctx, client, tx, job).

But very flexible here if you advise something else.

Observed on v0.39.0; the relevant code is unchanged on master.