feat(identity-resolution): make attribute policy and account assignment readable from the warehouse

[aleksdotbar]

Stacked on #2285 (person-attribute registry) — based on
feat/person-attribute-registry, so the diff shows only this change once
that merges.

Problem

The query path cannot see attribute policy or account-to-person assignment.
Policy is administrative state edited elsewhere; assignment is only implicit
in the persons journal. Without both readable from the analytical store, a
grouped or comparative request either consults a service it should not
depend on, or proceeds without knowing what it is allowed to do and who the
evidence belongs to.

Change

Two projections, reached two different ways.

• identity.person_attribute_policy_snapshot — a published snapshot.
  Policy crosses a store boundary, so it is copied: full snapshot, count
  verification, atomic swap. Keys stay the raw warehouse strings, so the
  relation joins the claim relations byte-equal.
• identity.person_account_assignments_current — a view. The persons
  journal is already in ClickHouse and is replaced wholesale by an atomic
  swap, so nothing needs copying: the view is consistent with its source by
  construction, and its revision is the journal's own publication stamp.
  Latest-wins is keyed by account rather than by person — the two disagree
  exactly when an account is rebound, which is the case this relation exists
  to resolve.

Supporting changes:

• Publishing mechanics (staging, count verification, watermark guard, atomic
  swap, staging GC) move into a writer shared with the persons-log publisher
  instead of being copied alongside it.
• publish-policy subcommand and hourly CronJob, journalled like the other
  runs. An unchanged policy set short-circuits, but only after confirming the
  published snapshot still matches what was journalled — a checksum alone
  would skip forever against a warehouse that had been wiped or re-pointed.
  Skips are journalled too, so the journal still answers whether the schedule
  fired.
• Journal GETs under /v1/person-attributes-policy-publish, behind the
  existing admin gate.
• The raw-identifier-to-UUID mapping becomes the insight_uuid_from_raw
  macro, replacing eight inline copies. It is the recipe for joining
  raw-keyed relations to identity ones, and writing it by hand is how such a
  join silently returns nothing.
• The stand seeder emits account-binding rows; without them the new view is
  empty on every seeded environment.

Fix carried along

CREATE DATABASE IF NOT EXISTS cannot run on a client pinned to that
database — ClickHouse resolves the request's database first and rejects the
statement. The persons-log publisher's fresh-environment path had therefore
never worked; it survived only because the init migration creates the
database. The bootstrap DDL now goes through a database that always exists.

Out of scope

The attribute catalog and the grouping and comparison APIs; mirroring the
account-person map (the projection contract deliberately allows swapping its
producer later).

Validation

• 105 unit tests; clippy pedantic clean; helm render-contract 29 green;
  dbt parse clean; OpenAPI drift gate passing on the regenerated spec.
• Against MariaDB 11.4 and ClickHouse 25.7.5: first run publishes; an
  unchanged set skips; a warehouse wiped behind the journal re-publishes
  rather than skipping; a policy edit republishes at the new revision; every
  run is journalled, skips included.
• Against seeded journal data: a rebound account resolves to the later
  person, email observations stay out of the projection, and the policy
  snapshot joins the assignment view through the documented recipe.

Notes for the consuming layer

• Policy joins the claim relations raw-to-raw; the assignment view joins them
  by hashing the claims side with insight_uuid_from_raw, account ids raw.
• An absent policy row must be treated restrictively — the decision to allow
  publishing an empty snapshot depends on it.
• Policy and assignment are pinned independently and refreshed by different
  jobs, so they are two diagnostics values, not one.

Closes #2312

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b4b126d-2d34-473f-9fef-975dba5b56b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}