fix(restore): max uid lease ignores uids that only appear as edge targets #9870

Description

After a restore, Zero's uid lease is bumped to the max uid the restore map phase saw. That max only covers uids that appear in keys, so a node that exists only as the target of a uid edge isn't counted. Zero can then hand that uid to a new node, and the new node silently inherits the restored incoming edges.

This affects both the online /admin restore and dgraph restore -z (once #9869 lands, since before that the offline path didn't bump the uid lease at all).

Root cause

In the map phase, processKV takes the max uid from the parsed key:

The object uids inside uid-edge posting lists are never looked at. A uid only shows up in a key if the node has at least one outgoing predicate, or if the incoming edge's predicate has @reverse.

Example

<0x1> <friend> _:new .

If _:new gets no predicates of its own and friend has no @reverse, its uid lives only in the posting list value of <0x1> <friend>. The newest node usually holds the highest uid, so this isn't a rare corner case. After restoring a backup taken at this point, the lease ends up below _:new's uid, and the next blank node assigned that uid picks up the friend edge from 0x1. Nothing reports an error.

I found this by reading the code while reviewing #9869 and haven't reproduced it end to end yet.

Possible fix

Decode uid posting values in the map phase and fold their uids into maxUid. That adds work proportional to the number of uid edges in the backup. A cheaper option would be to record Zero's max leased uid in the backup manifest when the backup is taken and bump to that on restore, but older backups wouldn't have it.