Consider automatically creating /etc/subuid and /etc/subgid entries

A user reports that using Podman as an authd user fails with:

```text
unable to copy from source docker://ubuntu:26.04: copying system image from manifest list: writing blob: adding layer with blob "sha256:08f5f5b2a2b0d2a960804adef3bd1783c5f2c20f42db5e290dc05d9529d11ae2"/""/"sha256:4a6e4a6c5956212bf74c556250eb0028096f13d74501e43af51a1dbed8d69749": unpacking failed (error: exit status 1; output: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/gshadow: invalid argument)
```

The error indicates that the authd user does not have sufficient subordinate UID/GID mappings to unpack the image.

`/etc/subuid` and `/etc/subgid` delegate subordinate UID/GID ranges that unprivileged users can map into child user namespaces. Rootless Podman is one consumer; other container and sandboxing tools use these mappings as well.

Entries for local accounts are normally created by `useradd`, `adduser`, or `newusers` when the account is created. authd users do not currently receive equivalent entries.

This raises the question of whether authd should automatically create subordinate UID/GID entries for authd users.

If this is supported, authd would need to define:

- how non-overlapping subordinate ranges are allocated;
- whether entries are keyed by username or numeric UID;
- what happens when an authd username or UID changes;
- how entries are removed when users are deleted; and
- how mappings are kept consistent after database restoration or other account-management changes.

If this is not intended to be supported, the limitation should be documented, along with a supported administrator procedure for configuring subordinate mappings for authd users.

No source file or test is named in the issue. First determine whether authd should create subordinate UID/GID mappings or document administrator configuration, then review the account-creation and deletion paths and existing tests for authd users. Done means the chosen policy covers allocation, identity changes, deletion, and restoration consistency, with documentation or tests for the supported behavior.

Written by the indexing model from the issue text.