[Feature Request] Set a user's Workforce Password Vault permission (AllowPersonalAccounts)

[DanPeterson]

Summary

Add a first-class way to set a user's Workforce Password Vault (WPV) permission — the
AllowPersonalAccounts flag on the user object — at creation time (New-SafeguardUser) and on an
existing user (Edit-SafeguardUser), or via a dedicated enable/disable pair.

Motivation

AllowPersonalAccounts is a standard boolean on the Safeguard user object that grants the Workforce
Password Vault (personal accounts) capability. It is a normal, supported user setting, but no cmdlet
exposes it:

• New-SafeguardUser cannot set it when the user is created.
• Edit-SafeguardUser exposes many scalar fields (first/last name, description, email, work/mobile
  phone, auth provider, admin roles) but not AllowPersonalAccounts.
• There is no Set-/Enable-/Disable- cmdlet for it.

The only ways to toggle it today are to fetch the whole user object, mutate the field, and round-trip
it, or to PUT the raw object:

$u = Get-SafeguardUser -UserToGet $id
$u.AllowPersonalAccounts = $true
Edit-SafeguardUser -UserObject $u
# or, entirely by hand:
Invoke-SafeguardMethod Core PUT "Users/$id" -Body $u

Both require the caller to know the internal field name and re-submit the full object just to flip one
flag.

Proposed API (either shape works)

# Option A: a switch/parameter on the existing cmdlets
New-SafeguardUser  [...] [-AllowPersonalAccounts]
Edit-SafeguardUser [-UserToEdit] <o> [-AllowPersonalAccounts <bool>]

# Option B: a dedicated enable/disable pair
Enable-SafeguardUserPersonalAccount  [-UserToGet] <o>
Disable-SafeguardUserPersonalAccount [-UserToGet] <o>

Current workaround

Fetch the user, set .AllowPersonalAccounts, and re-submit via Edit-SafeguardUser -UserObject, or
raw PUT Users/{id}.