persist: idgen counter restarts after restore, so new IDs collide with restored ones #1549

After a serve --persist restart (or any snapshot restore), the process-wide idgen counter starts again from a low number. IDs minted after the restore can then match ones that were restored, and the new resource overwrites the old one in its store.

Seen in review on the OCI PRs (#421 ONS subscriptions; #422 object versions, retention rules, bucket OCIDs), but every provider that builds IDs from the shared counter is affected.

Repro (ONS): create a subscription, restart with --persist, then create another subscription. The new one takes the OCID of the restored one and replaces it.

Possible fixes:

• persist the counter's high-water mark in the snapshot and restore it before any service mints, or
• seed the counter after restore from the highest restored ID, or
• move OCID suffixes to random IDs (idgen.UUID()-style) where the shape allows.

Per-service workarounds (random suffixes) are going into the OCI PRs where a reviewer flagged them. This issue tracks the general fix.