Test data strategy: generate a canonical party-identity record, derive scenario CSVs

### Context

The k6 test data in `K6/testdata/` (~60 CSVs) has grown organically. Looking at the *shape* rather than the contents, almost every file is a projection of one underlying record: **a party identity fully resolved to its Altinn identifiers**. The most complete schema already exists in the delegation "v2" files:

```
orgNo, partyId, ssn, userId, userPartyId, orgUuid, partyUuid, lastName
```

Everything else is a subset or pairing of it (`orgs-dagl` = `orgno,ssn`; `consenter-persons` = `ssn,partyUuid`; `pdp/*` = two records paired). So it is effectively **~1 canonical record, projected into ~15 shapes, duplicated across 4 environments and 2 volume tiers** (small at22/at23/tt02 for functional/smoke, large yt01 for load).

### Problems today

- **Naming/casing chaos** for the same concept: `ssn`/`pid`/`Pid`/`tossn`, `orgno`/`orgNo`/`Org`/`fromorg`.
- **Misleading names**: in delegation files `partyId` = the org's party id but `partyUuid` = the person's.
- **Quoting drift**: `pdp/tt02` quotes headers, `pdp/yt01` doesn't — and yt01's org-user file silently dropped the `task` column.
- **Live schema drift**: `orgs-in-*-with-party-uuid.csv` vs `…-v2.csv`, both in use.
- **Coverage gaps + hand duplication**: data maintained manually per scenario/env; identities re-materialized by hand.

### Proposed strategy

1. **One canonical schema + naming convention** — adopt the v2 columns, disambiguate org vs person (e.g. `orgNo,orgPartyId,orgUuid,ssn,userId,userPartyId,userPartyUuid,lastName`), documented once.
2. **Pipeline: seed → enrich → project** — Tenor produces env-independent seeds (ssn/orgNo + role: daglig leder, kontaktperson); register bulk-resolves env-specific ids (partyUuid/partyId/userId/lastName, 100 at a time); scenario CSVs become deterministic projections of the canonical record. _(In progress: `tools/tenor-testdata/`.)_
3. **Size by tier via a flag** — small for at2x/tt02 (functional), large for yt01 (load).
4. **Deterministic + regenerable** — seeded generation; a `regenerate` command to refresh stale data.
5. **Lint the data in CI** — validate header matches canonical schema, ssn/orgno well-formed, no unquoted commas.