Security hardening of token and HMAC signing

Problem/Motivation

HMAC capabilities are derived inconsistently from hash_salt alone in five of seven places, while core's convention and two ACT paths use private_key with hash_salt. hash_salt is commonly committed or copied between environments, so those signatures are weaker than intended. The act_reply_scope capability is a permanent, never-rotating per-user secret with no expiry or session binding (a site-wide constant for anonymous users). The versions hash also commits to admin-only fields (mail, hostname), forming a change-detection oracle.

Steps to reproduce

• Inspect the signed capabilities: five use hash_salt alone, two use private_key plus hash_salt.
• Confirm act_reply_scope never changes for a user and is a site-wide constant for anonymous users.

Proposed resolution

• Derive all capabilities from private_key with hash_salt.
• Add an expiry and optional session binding to act_reply_scope, validated on use.
• Replace the versions hash with a non-sensitive token (cid:changed:status:childCount).

Remaining tasks

• Add tests for expiry and rotation.

User interface changes

None.

API changes

Signed capabilities are keyed consistently and carry expiry.

Data model changes

None anticipated.

AI-Generated: Yes (Used Opus 5 and DeepSeek Flash to review and discover these issues)