fix(replica): least-privilege extra users and analytics role, with per-schema access

[julianam-w]

Summary

Extra users (extraUsers) and the analytics role were provisioned with more privilege than intended, and a name colliding with a role in the source cluster could keep that role's production access. This PR closes those gaps and adds a new capability: extra users can now be scoped to read specific schemas.

Privilege fixes

• Extra users are no longer LOGIN SUPERUSER. They're reset to a plain LOGIN role with no privileges of their own and read-only sessions, regardless of the replica's readOnly setting.
• The analytics role is reset on every restore, not just when first created — a name matching analyticsUsername that collided with a production role previously kept that role's attributes.
• Ownership and direct grants are now stripped on collision. A colliding role's REASSIGN OWNED BY ... TO postgres (keeps the objects) then DROP OWNED BY (drops remaining direct grants) — previously only attributes/password/memberships were reset, so a colliding role kept whatever it owned or had been granted directly.
• The PUBLIC lockdown is now database-wide, not just the public schema's own ACL: every non-system schema, table/view/sequence/matview/foreign table, function, and default-privilege entry.
• The lockdown runs unconditionally on every restore, not just when extraUsers is declared — gating it left a one-way, undocumented revoke behind if a replica's last extra user was later removed.
• Fixed unescaped SQL interpolation: analyticsUsername was spliced raw into SQL string literals; it now goes through the same parameterized psql -v + %I/%L pattern as extra users (which also collapsed two divergent, hand-duplicated SQL blocks into one shared role_reset_block helper).
• Revoking PUBLIC's function EXECUTE cost the PG≥14 read-only analytics user something pg_read_all_data doesn't cover — that branch now grants EXECUTE back explicitly.
• Fixed a stale crds.yaml description for analyticsUsername that no longer matched the README.

New capability: per-user schema access

extraUsers is now []{name, schemas} instead of []string:

extraUsers:
  - name: reporting
    schemas: [public]
  - name: dbt_reader
    schemas: [dbt, staging]

A listed schema grants USAGE + SELECT on current tables/sequences (silently skipped in a database where the schema doesn't exist), plus default privileges so tables the persistent-schemas migration creates afterwards (as the analytics role) are covered without a second grant step. These run after the ownership/direct-grant strip above — granting first would have DROP OWNED BY revoke it again immediately.

The canopy extra_users param is now name or name:schema1+schema2 per entry, comma-separated between entries — canopy's param types have no structured/array option, so this stays one opaque text field.

Known gaps (not addressed here, disclosed rather than hidden)

• persistentSchemas set (or migrate_to without redaction) still keeps the analytics role at SUPERUSER for the restore's whole life, regardless of readOnly — pre-existing, out of scope for this PR.
• No integration test covers the actual name-collision-with-ownership scenario (it requires seeding a role with ownership into the source snapshot before restore, which the test harness has no fixture for). Unit tests verify the generated SQL directly instead.

Testing

• cargo fmt / cargo clippy --all-targets --all-features: clean.
• Full lib test suite: 331/350 passing. The 19 failures are pre-existing and unrelated — canopy's live-fetched OpenAPI now requires a machine_id field the test fixtures don't set.
• Every integration test binary in the workspace compiles (cargo test --no-run --workspace); they're #[ignore]'d and need a real cluster to run — see tests/extra_users.rs for the updated/extended coverage.
• crds.yaml verified byte-for-byte against a fresh gen-crds run.

🤖 Generated with Claude Code

[passcod]

Happy in principle but please drive the CI to green :)