Soft-deleted-user restore + identity-attach explicit two-step design

When an access request matches a SOFT-DELETED user row, restoring that user AND binding a new Google identity to it is a distinct risk surface (dormancy/restore semantics + hidden authz/role resurrection). PLUTO-617 fails that branch CLOSED to human decision — it does NOT auto-restore+bind. This WI designs the explicit two-step: (1) admin explicitly reactivates the soft-deleted user (separate deliberate action, restores authz state visibly), THEN (2) attach the requester's Google identity under the same identity CAS as the live-attach path. Approve must never implicitly resurrect authorization + bind identity in one step. Ref: pluto-dormancy-swept-stub-restore-not-approve. Gated on PLUTO-617 landing (reuses its resolver + CAS attach).