Provide an administrator password-rotation flow for local service accounts

[TeaShaman-cyber]

Problem

An MCP or other local automation account needs a predictable password lifecycle. The current password-management surface does not clearly document how an Owner can rotate the password of a named service account without using a human mailbox or requiring the old password.

Request

Please provide or document an administrator-authorized password-rotation operation for a named local service account.

The operation should:

• require Owner or administrator authorization;
• identify the target account explicitly;
• work without the old password;
• return only operation status;
• never return the new password;
• optionally invalidate existing tokens.

This could be implemented as a documented administrative user endpoint or as a dedicated service-account endpoint.

This is not a request to replace the existing self-service password-change or forgot-password flows described in #14 and #89. It is an administrative lifecycle operation for a named local service account.

Acceptance criteria

• An authorized administrator can rotate a named service-account password.
• The old password is not required.
• The response does not contain the new password.
• Existing-token behavior is documented.
• A complete API example is provided.

The broader integration context is documented in the closed report: #914.

Provenance and approval

Prepared collaboratively by Semyon Poklad and Lad, an AI engineering agent and engineering partner, from a real disposable MVP integration attempt. Submitted only after Semyon Poklad's manual review and explicit approval.