Test policylesingen: GET /resource/{id}/policy, /policy/rules og /policy/subjects

**Testdata: én permanent ressurs, ikke en ny per kjøring.** Konklusjonen i #488 er at det ikke er bærekraftig å opprette og slette ressurser fortløpende, fordi slettingen etterlater rader i `resourceregistry.resourcesubjects` som ingenting rydder, meldt som Altinn/altinn-resource-registry#848. Denne testen skal derfor ikke opprette og slette noe per iterasjon. Den skal bruke én ressurs med hardkodet identifikator og kjent policy, som opprettes én gang og blir liggende, og som testen aldri sletter. Da blir residuet et konstant antall rader per miljø i stedet for et par nye rader hvert kvarter.

Det som må bestemmes er hvordan ressursen kommer på plass i de miljøene vi kjører i. Enten seedes den én gang utenfor testen, eller testen leser den først og oppretter den bare hvis den ikke finnes. Det siste holder testen selvstendig, men gjør at det aller første løpet i et nytt miljø skriver.

De tre endepunktene leser policyen til en ressurs på hver sin form. `/policy` gir XACML-dokumentet slik det ble lastet opp, `/policy/rules` gir flate regler med én subjekt, handling og ressurs per regel, og `/policy/subjects` gir en paginert liste over subjektene som forekommer i policyen, med en valgfri `reloadFromXacml`. Vi leser i dag bare `/policy/rights`, som er den fjerde formen.

Clientene `ResourceGetPolicy`, `ResourceGetPolicyRules` og `ResourceGetPolicySubjects` finnes, og byggeblokkene `get-policy.js`, `get-policy-rules.js` og `get-policy-subjects.js` også. Ingen av de tre importeres.

Testen bør opprette en ressurs med en policy den kjenner innholdet av, slik `create-resource-and-policy.js` gjør, og deretter sjekke at de tre formene beskriver den samme policyen: at XACML-svaret inneholder rollene og handlingene som ble lastet opp, at de flate reglene dekker hver kombinasjon av subjekt og handling, og at subjektlisten inneholder nøyaktig rollene og tilgangspakkene policyen ga tilgang til.

Åpent spørsmål: hva `reloadFromXacml=true` skal sjekkes mot. Den tvinger en ny lesing fra XACML-dokumentet, og det er ikke opplagt hva som er den observerbare forskjellen på en fersk ressurs.

Scope: lesingen krever ingenting. Alle tre metodene ligger på `ResourceController` uten `[Authorize]`, og klassen har ikke noe på klassenivå, så `/policy`, `/policy/rules` og `/policy/subjects` er anonyme (`src/Altinn.ResourceRegistry/Controllers/ResourceController.cs` på main). Det som krever scope er arrange-steget: å opprette ressursen og laste opp policyen går på `POLICY_SCOPE_RESOURCEREGISTRY_WRITE`, altså `altinn:resourceregistry/resource.write` eller `resource.admin`, som `create-resource-and-policy.js` alt skaffer seg. Selve lesingen bør gjøres uten token, slik at testen samtidig viser at endepunktene er åpne.

Del av #473

Start with create-resource-and-policy.js, the existing get-policy.js, get-policy-rules.js, and get-policy-subjects.js building blocks, and ResourceController.cs to confirm the read endpoints are anonymous. Decide how the permanent resource is seeded and what reloadFromXacml=true should demonstrate. Done means the test reads all three endpoints without a token and verifies their results against the known policy roles, subjects, and actions.

Written by the indexing model from the issue text.