LDAP groups created in Active Directory get an auto-generated sAMAccountName

## Environment

- defguard core 2.1.0, installed from the APT repository on Ubuntu 26.04
- Business license, LDAP sync against Active Directory (`ldap_uses_ad = true`)
- `ldap_is_authoritative = true`, group search base `OU=Defguard,...`
- `ldap_groupname_attr = cn`, `ldap_group_obj_class = group`

## Problem

When defguard creates a group in Active Directory it sends only `objectClass`, `cn` and `member`
(`crates/defguard_core/src/enterprise/ldap/mod.rs`, `add_group_with_members`, ~line 895).
No `sAMAccountName` is sent, so AD generates a placeholder such as `$V31000-U46U2D83SO25`.

For users defguard already handles this: in AD mode it sets `sAMAccountName` explicitly
(`enterprise/ldap/model.rs`, ~line 177). Groups are not covered.

Renaming a group from defguard (`PUT /api/v1/group/{id}` → `modify_group`, modrdn) changes `cn`
but leaves the old `sAMAccountName` in place, so the two drift further apart with every rename.

## Why it matters

`cn` is what defguard matches on, so the sync itself works. Everything on the Windows side that
addresses a group by its pre-Windows 2000 name breaks or becomes unreadable:

- `whoami /groups` on a client shows `DOMAIN\$V31000-U46U2D83SO25` instead of `DOMAIN\DG-FiBu`
- `Get-ADGroup -Identity DG-FiBu` and `net group DG-FiBu` fail (they resolve via sAMAccountName)
- GPO security filtering, scripts and logon troubleshooting all show the placeholder

Groups created by hand in ADUC do not have this problem, because ADUC fills the field from `cn`.

## Steps to reproduce

1. Configure LDAP sync against AD with a group search base.
2. In defguard, add a synced user to a group that does not exist in AD yet, e.g. `DG-Test`.
3. Defguard creates `CN=DG-Test,OU=...` in AD.
4. Inspect the object: `Get-ADGroup -LDAPFilter "(cn=DG-Test)" | Select Name, SamAccountName`.

## Expected result

`SamAccountName` equals `DG-Test`, the same way ADUC and `New-ADGroup` behave.

## Actual result

`SamAccountName` is `$`.

## Suggested fix

When `ldap_uses_ad` is true, derive `sAMAccountName` from the group name instead of leaving it to AD:

- strip the characters AD does not accept (`" / \ [ ] : ; | = , + * ? < >`) and any trailing period
(length is not an issue: `cn` is limited to 64, `sAMAccountName` for groups allows 256);
- `add_group_with_members`: send the result as `sAMAccountName`; if AD still rejects the add
(the value must be unique per domain, `cn` only per container), retry once without the
attribute so AD falls back to the generated name;
- `modify_group` (rename): replace `sAMAccountName` the same way.

This keeps the current behaviour as a fallback and does not add any validation that would reject
group names users can create today.

## Workaround

Fix the attribute once from PowerShell (the groups cannot be addressed by `-Identity`):

```powershell
Get-ADGroup -LDAPFilter "(cn=DG-*)" -SearchBase "OU=Defguard,..." |
ForEach-Object { Set-ADGroup $_ -SamAccountName $_.Name }
```

This has to be repeated after every rename done from defguard.