feat: add password strength policy UI

[HarshMN2345]

What does this PR do?

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR adds a new PasswordStrengthPolicy card to the auth security page, letting admins configure minimum password length and required character classes (uppercase, lowercase, number, special character). It also refactors passwordPolicies.svelte to use explicit saved* state snapshots and per-policy change guards instead of always calling all three update endpoints.

• New component (passwordStrengthPolicy.svelte): renders an InputNumber (min 8, max 256) and four checkboxes; submits via updatePasswordStrengthPolicy; uses @appwrite.io/console@5d0672f which adds Models.PolicyPasswordStrength and ProjectPolicyId.Passwordstrength.
• passwordPolicies.svelte refactor: introduces saved* state to track the last-persisted baseline and skips unchanged API calls, improving efficiency and error attribution; the saved* values are currently set from local form state before await invalidate resolves (see inline comment).
• +page.ts: adds passwordStrengthPolicy to the load return value with a sensible default fallback when the policy is absent from the API response.

Confidence Score: 4/5

The new strength policy component and load changes are straightforward; the main risk is in the refactored passwordPolicies.svelte where saved-state snapshots are written from local form values before the invalidate round-trip completes.

The new passwordStrengthPolicy.svelte component has no saved-state snapshots — hasChanges derives directly from the live policy prop, so the form state is never explicitly reset after a successful save. The refactored passwordPolicies.svelte sets saved* values before await invalidate resolves, meaning server-normalised responses are not reflected in the baseline.

passwordStrengthPolicy.svelte and passwordPolicies.svelte both warrant a closer look at the post-save state reset logic.

Important Files Changed

Filename	Overview
src/routes/(console)/project-[region]-[project]/auth/security/passwordStrengthPolicy.svelte	New component for password strength policy — missing saved-state snapshots; hasChanges compares against the live policy prop and form state is never reset after a successful save, which can leave the Update button in an incorrect state if the server normalises values.
src/routes/(console)/project-[region]-[project]/auth/security/passwordPolicies.svelte	Refactored to use saved* state snapshots and per-policy change guards; saved* values are committed from local form state before await invalidate resolves, so server normalization would silently diverge the snapshot from the actual persisted state.
src/routes/(console)/project-[region]-[project]/auth/security/+page.ts	Adds passwordStrengthPolicy to the load return value with a sensible default fallback when the policy isn't returned by the API.
src/routes/(console)/project-[region]-[project]/auth/security/+page.svelte	Imports and renders the new PasswordStrengthPolicy component, placed before PasswordPolicies in the layout.
src/lib/actions/analytics.ts	Adds AuthPasswordStrengthUpdate to the Submit enum — clean, follows the existing naming convention.
package.json	Bumps @appwrite.io/console to a new hash-pinned version that likely introduces Models.PolicyPasswordStrength and ProjectPolicyId.Passwordstrength.

_{Reviews (2): Last reviewed commit: "all five inlined" | Re-trigger Greptile}