Derive address of account from hash of credential id and sender

[citizen-stig]

Description

Why

When InsertCredentialId registered a new credential, the account's address was set to the sender's own address. Two consequences:

• Multisig security. A multisig registered by user A aliased A's address. A later compromise of A's single key would silently also control the multisig.
• Defense in depth for future credential removal. If removal is ever added, a removed credential could be resurrected against the same address by another sender.

How

• New credential → new address is now derived as hash(new_credential_id || sender), routed through CredentialId → S::Address so the 32-byte hash adapts to each spec's address width (28 / 32 / 20) without per-spec branching.

Impact

• Breaking behavioural change. Callers must no longer assume a newly-registered credential points back at the sender. Multisigs in particular need explicit funding after registration.
• No new proved state, no new cross-module dependency, no Context surface change.
• Follow-up planned (separate PR): also mix the signer's sov-uniqueness nonce + next_generation into the hash, giving temporal separation against same (credential, sender) re-registration. Requires plumbing credential_id through
  Context. out of scope here.

This is RESYNC BREAKING for all rollups that have enable_custom_account_mappings enabled

---

• I have updated CHANGELOG.md with a new entry if my PR makes any breaking changes or fixes a bug. If my PR removes a feature or changes its behavior, I provide help for users on how to migrate to the new behavior.
• I have carefully reviewed all my Cargo.toml changes before opening the PRs. (Are all new dependencies necessary? Is any module dependency leaked into the full-node (hint: it shouldn't)?)

Testing

Tests are updated.

Docs

No updates

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.