PostgreSQL 17.11 initdb on Windows: restricted-token errors 87 and 0 despite exit status 0

Hello PostgreSQL community,

I would appreciate technical guidance on a restricted-token bootstrap
failure, rather than assuming a PostgreSQL defect.

Environment:
- Windows 10 Pro 22H2, build 19045.6466, x64.
- PostgreSQL 17.11; postgres --version was checked.
- The launching process was already restricted and non-elevated, as
observed through read-only token queries.

A single previous invocation used:
initdb.exe -D <temporary-local-directory>/data -U bootstrap_fixture
--auth=reject --no-locale --encoding=UTF8

initdb returned exit status 0. Its stdout reported successful
initialization, and PG_VERSION (17) and global/pg_control existed.
However, stderr contained these Portuguese messages:

initdb: erro: não pôde criar informação restrita: código de erro 87
initdb: erro: não pôde executar novamente com informação restrita:
código de erro 0

These correspond to failure to create a restricted token and failure
to re-execute with a restricted token. We treated this as a failed
security stage, did not attempt pg_ctl start, and removed only the
owned temporary runtime. No application SQL was run.

Reviewing REL_17_11 src/common/restricted_token.c suggests that the
helper logs this failure but can return to initdb. It also appears
that GetLastError is sampled after FreeSid/CloseHandle, and again
after logging. We therefore do not have the immediate error from the
original API call and do not claim that the reported 87 identifies a
particular invalid argument.

No internal restricted-execution bypass was forced, no direct
server-start workaround was attempted, and no OS or sandbox security
settings were changed.

Could you advise:
1. Is there a known supported fix or restriction-preserving execution
procedure for this situation?
2. Is this nonfatal continuation expected, and what reliable
diagnostic signal should be used in addition to exit status?
3. What minimal supported diagnostic information would help
distinguish a PostgreSQL issue from an interaction with an
already-restricted Windows execution context, without repeating
cluster initialization or weakening isolation?

This message contains only sanitized technical observations and no
database data or attachments. We are not requesting paid support.

Thank you.