Centralise test and demo passwords and guard them against policy changes

Start with application/common/src/PasswordStrength.ts, application/common/testing/constants.ts, and the named backend and Cypress examples to map existing policy checks and password literals; coordinate timing with the listed prerequisite issues, which edit the same test files. Then implement the shared password module and guard test described in the issue, including the API drift check if in scope. Done means the acceptance criteria hold and backend, common, and both client test suites pass.

Follow-up to #899. Best picked up once #899, #910, #927, #937, #948 and #888 have merged, since they all edit the same test files and some add new test passwords.

Every time the password policy changes, someone has to search the repo by hand for test, seed and demo passwords that no longer pass. That search is easy to get wrong, and the misses show up late or not at all.

Problems

Passwords are hand-written all over the test suite. TestUsers in application/common/testing/constants.ts is the only shared home, and it only covers seeded users. Most backend tests and Cypress specs make up their own, for example Loginforbogusperson1 in AuditLogsController.test.ts, Aadsfoswefw1515fd@! in user-client/cypress/e2e/registration.cy.js, and the fillRegistrationForm default in common/cypress/support/commands.ts. The open PRs add a few more, such as Constellation-battery-24! in #927. #910 also adds a second shared value, STRONG_TEST_PASSWORD, next to TestUsers.

Policy changes are found late, or never. #868 raised the minimum length from 8 to 14 and had to touch dozens of test and fixture files. In #899, adding common words meant updating example passwords. The review listed a handful of files and a search turned up more, including the fillRegistrationForm default, which would only have failed in the cross-app Cypress suite after merge. The old TestUsers admin password broke too, and it showed up as failing integration tests rather than pointing at the value.

Seeding itself never breaks, because the seed scripts hash passwords without checking strength. What breaks is any test that types a seeded password into register, reset or setup.

Nothing checks the public demo login. When secret joined the common-word list, README.md, .env.example and the Helm demo-reset job were all advertising a password the app rejects. No test failed. It was caught in review.

Negative tests depend on the order the rules run in. For example, user-client/cypress/e2e/passwordReset.cy.js expects the error for Asdfasdfasdfasdf to start with the "number" rule. If a matching word ever joins the list, the common-word message comes first and the test breaks, even though the password still has no number.

The policy itself is defined in more than one place. The minimum length lives in checkPasswordStrength and in @minLength comments on the request types, which #937 brings down to one Password type. tsoa reads those comments, so they can't reference a constant (#871). commonPasswordBaseWords sits in a test-data file even though production code imports it. The existing length tests send passwords far below the minimum (pass, weak), so they still pass if the API's minimum and checkPasswordStrength drift apart by a few characters.

Suggested solution

1. One module for test and demo passwords. Add application/common/testing/passwords.ts with a valid password, the demo password, and a set of invalid ones built from the policy, each breaking exactly one rule:

export const VALID_PASSWORD = 'Constellation2026' // replaces STRONG_TEST_PASSWORD from #910
export const DEMO_PASSWORD = 'Consentdemo123'
export const INVALID_PASSWORDS = {
  tooShort: 'Aa1'.padEnd(PASSWORD_MIN_LENGTH - 1, 'x'),
  commonWord: `${VALID_PASSWORD}${commonPasswordBaseWords[0]}`,
  noUppercase: VALID_PASSWORD.toLowerCase(),
  noLowercase: VALID_PASSWORD.toUpperCase(),
  noNumber: VALID_PASSWORD.replace(/\d/g, 'x'),
}

Backend tests, Cypress specs and fillRegistrationForm import from it instead of writing literals. TestUsers stays the home for seeded users. Login tests that only need a wrong password can keep a literal, since login doesn't run checkPasswordStrength. #937 does put @minLength 14 on LoginRequest.password, so those literals still have to meet the minimum length.

2. A guard test. application/common/testing/passwords.test.ts runs in test (common) on every PR and checks that:

• every TestUsers password, VALID_PASSWORD and DEMO_PASSWORD passes checkPasswordStrength. After #910, it also passes each seeded user's name and email
• each invalid password fails for exactly its one rule
• README.md, .env.example and the Helm cron.yaml contain DEMO_PASSWORD

A PR that adds a common word or changes a rule then fails on its own CI and names the value to change.

3. One home for the policy.

• Export PASSWORD_MIN_LENGTH from application/common/src/PasswordStrength.ts and move commonPasswordBaseWords there.
• Keep @minLength on the Password type as a literal, with a // comment pointing at PASSWORD_MIN_LENGTH.
• Add a test through the API that catches the two drifting apart, for example POST /users/password/reset with an invalid token returning 422 just under the minimum and 403 at it.
• Build the "at least 14 characters" text in the Cypress specs from PASSWORD_MIN_LENGTH.

Parts 1 and 2 belong together, because the guard can only see passwords that live in the module. Part 1 needs the PASSWORD_MIN_LENGTH export from part 3, so that export goes in the first PR. The rest of part 3 can go in the same PR or a second one.

Acceptance criteria

• Test passwords that must pass the policy come from passwords.ts or TestUsers, apart from the demo-login files and integrations test data
• Adding a word used by any fixture to commonPasswordBaseWords fails the guard test, naming the fixture
• Changing the minimum length in one place but not the other fails the drift test
• Backend, common and both client test suites pass

Considerations

• If #871 (Zod) goes ahead, the schema can use PASSWORD_MIN_LENGTH directly and the drift test goes away. ADR-000 in #937 chose the commonTypes.ts refactor over Zod for now.
• A CI check for stray password literals is possible but needs an allowlist for deliberate bad passwords. A line in the PR template may be enough to start.
• The docs site lives in ctrl-docs, so the guard can't check it.

Related: #889, #868, #871, #888, #899, #910, #927, #937, #948