v0.4.1

Repairs the metadata on objects the server writes itself.

What was wrong

Pools provisioned by a class cascade, and the IPAllocation a claim materialises, are written straight into the object table rather than POSTed, so neither passed through the create path that stamps metadata.uid and metadata.creationTimestamp. Every provisioned pool reported 0001-01-01T00:00:00Z and carried no UID, and nothing could take an owner reference to one.

The fix

Both write paths now stamp the fields before the insert.

Migration 005 repairs existing rows: the creation timestamp comes from the row's own created_at, so a repaired object says what it would have said at the time, and the UID is generated. Rows are reversioned with a MODIFIED changelog entry so watches opened before the migration do not keep serving the unstamped object. Documents that already carry both fields are left untouched.

The migration applies automatically on rollout and is safe on a populated database. There is no down-migration: nothing records which document was missing which field, and stripping every UID and timestamp would break the objects that always had them.

Verified in staging

Migration applied in 117ms. All 150 previously-unstamped objects repaired (51 of 53 IPPool, 99 of 99 IPAllocation), each timestamp matching its row's created_at. IPClaim and IPClass were already correct and were not touched.