Add helper for job metadata updates

[peter941221]

1. Adds a small public SetMetadata(ctx, key, value) helper for writing metadata updates onto the existing work-context merge path.
2. Keeps the surface intentionally narrow: no batch API, no delete API, no hook signature changes, and no completion semantics changes.
3. Rejects river:-prefixed keys so user code can't collide with River-reserved metadata keys.
4. Adds focused coverage for the helper contract itself plus worker and HookWorkEnd integration paths.

Closes #1218.

Verification:

1. go test ./... -run "TestSetMetadata|Test_Client_Common/(WithWorkerSettingMetadata|WithWorkEndHookSettingMetadata)" -count=1
2. make test

[brandur]

Cool! Seems useful. I like the touch that we reject use of the river:* namespace.

[peter941221]

Thanks. I dropped the unrelated CLI and worker.go changes, scoped the test-only job args into the test case, and normalized the error message casing.

[peter941221]

One note on the remaining red check: the retriggered run moved the failure from build_and_test (1.26, 15) to build_and_test (1.26, 14), and both failures happened during Docker pull for postgres:15 in container setup rather than during test execution, so this looks like CI flakiness rather than a code regression.\n\nLatest run: https://github.com/riverqueue/river/actions/runs/26804256615

[brandur]

@peter941221 Was just thinking about this a bit more today, and could you rename GetMetadata to MetadataGet?

It's a bit more of a mouthful, but since this is a top-level package function, using a Metadata* prefix means it'll stay sorted with alike functions if we end up adding more functions later (e.g. MetadataClear, MetadataDelete, or something like that).

It's also consistent with how things are named on Client like JobGet vs. JobList.

[peter941221]

Renamed the helper to MetadataSet in d8e114f so the top-level metadata helpers stay grouped under Metadata*.

[brandur]

@peter941221 Great, thanks! Okay, this is looking good. Can you add a CHANGELOG entry? Put it under the "added' section.

[peter941221]

Added the CHANGELOG entry under Unreleased -> Added in c0e0902.

[peter941221]

The red check was another windows-latest postgres bootstrap failure in action-setup-postgres before checkout or CLI execution. I pushed a no-op commit to retrigger CI on a fresh runner.

[brandur]

Thanks! Yeah, we definitely have a couple GItHub Actions-related flakes going on.