Fix unique-by-args handling of literal JSON keys

[bgentry]

This fixes UniqueOpts.ByArgs incorrectly skipping distinct jobs when their JSON field names contain dots or other characters that River interprets as path syntax.

A dot is allowed in a JSON key. This object has one top-level key named user.id:

{"user.id": "u1"}

River's uniqueness code mistakenly reads that key name as a path to an id field inside a user object, as though the args had this different shape:

{"user": {"id": "u1"}}

The lookup finds nothing in the actual args, so the user ID is left out of the unique key. Jobs for different users then look like duplicates.

An application can explicitly choose the dotted JSON name with a struct tag:

type SyncUserArgs struct {
    UserID string `json:"user.id" river:"unique"`
}

func (SyncUserArgs) Kind() string { return "sync_user" }

encoding/json writes the first JSON shape above. It does not turn the dot into nesting, and River does not automatically rename UserID to user.id. The example uses an unusual but valid JSON name; a conventional json:"user_id" tag is unaffected.

With UniqueOpts{ByArgs: true}, these successive insertions now behave correctly. Assume no matching jobs exist initially and the inserted jobs remain available:

Args	Before	After
SyncUserArgs{UserID: "u1"}	Inserted	Inserted
SyncUserArgs{UserID: "u2"}	Skipped as a duplicate of u1	Inserted
SyncUserArgs{UserID: "u1"} again	Skipped as a duplicate	Skipped as a duplicate of u1

The fix also covers uniqueness based on all args, without river:"unique" tags. For example, {"file.name":"a.txt"} and {"file.name":"b.txt"} previously collided; now both jobs are inserted. An empty key such as {"":"a"} previously failed with path cannot be empty; now it inserts normally, and changing its value produces a distinct job. Keys containing other path syntax, such as alice@example.com or a leading :, are also treated literally.

A related fix handles unnamed JSON tags, such as this field:

Recipient string `json:",omitempty" river:"unique"`

Go uses the JSON key Recipient, but River previously looked for an empty key, so different nonempty recipients collided. River now uses the Go field name too. An omitted recipient remains omitted.

Internally, tagged fields use escaped gjson/sjson path components. When all args participate in uniqueness, River walks the top-level object directly and rebuilds it in key order using its raw values.

Unaffected args keep byte-for-byte identical unique keys. Affected jobs receive corrected keys, so a job inserted before upgrading may no longer deduplicate an identical insertion after upgrading; during a rolling upgrade, old and new clients may each insert it.

A before/after UniqueKey microbenchmark on Go 1.27.1 / Apple M4 Pro found no statistically significant time change for ordinary flat or nested tagged fields, with unchanged allocations. All-args cases with 0, 1, 8, and 64 keys were 25–89% faster and allocated less. An unusual two-field case using $amount and Y was 3.8% slower (about 20 ns), with 32 extra bytes and three extra allocations per call. These measurements use ten alternating before/after samples with the field cache warmed and exclude JSON marshaling and database work.

[brandur]

Wanna ask Claude for a quick benchmark just to make sure that there isn't a serious perf regression on the unique path here?

[brandur]

There is a ton of identical verbiage in these two entries. Maybe there's two separate issues in a technical sense, but I don't think the technical correctness is worth the added verbosity. Do you want to condense them down to one?

[bgentry]

Thanks for catching, I cleaned this up a lot! 🙏

[brandur]

Awesome. Thoughts on the benchmark?

[bgentry]

Awesome. Thoughts on the benchmark?

Bah, sorry, I thought I wrote this in my comment to you but must have gotten distracted and forgotten to. The PR description was updated with the benchmark results previously, it turns out this new version is actually slightly faster or a wash.

A before/after UniqueKey microbenchmark on Go 1.27.1 / Apple M4 Pro found no statistically significant time change for ordinary flat or nested tagged fields, with unchanged allocations. All-args cases with 0, 1, 8, and 64 keys were 25–89% faster and allocated less. An unusual two-field case using $amount and Y was 3.8% slower (about 20 ns), with 32 extra bytes and three extra allocations per call. These measurements use ten alternating before/after samples with the field cache warmed and exclude JSON marshaling and database work.