Test PUT /resource/{id} og PUT /resource/{id}/policy

**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 to endepunktene oppdaterer en ressurs som alt finnes: metadata med `PUT /resource/{id}` og policyen med `PUT /resource/{id}/policy`. Policy-oppdateringen er den samme metoden i kontrolleren som POST-varianten vi alt treffer, bare med et annet ruteattributt, så den er nesten gratis når oppdateringstesten først finnes.

Clientene `ResourceUpdateResource` og `ResourceUpdatePolicy` finnes, byggeblokkene `update-resource.js` og `update-policy.js` også, og ingen av dem importeres. Begge krever `altinn:resourceregistry/resource.write`, som `create-resource-and-policy.js` alt skaffer seg.

Testen bør bygge videre på mønsteret fra `create-resource-and-policy.js`: opprett en ressurs, endre et felt (for eksempel tittel eller `delegable`), les den tilbake og sjekk at endringen slo gjennom, last opp en ny policy med en ekstra handling, les rettighetene og sjekk at den nye handlingen dukket opp, og slett til slutt.

Åpent spørsmål: om dette skal bli en egen test eller flere steg i `create-resource-and-policy.js`. Å utvide den eksisterende gir færre ressurser som må ryddes, men gjør den lengre.

Scope: `PUT /resource/{id}`, `POST /resource/{id}/policy` og `PUT /resource/{id}/policy` går alle på `POLICY_SCOPE_RESOURCEREGISTRY_WRITE`, som godtar `altinn:resourceregistry/resource.write` eller `altinn:resourceregistry/resource.admin`. Ingen av dem trenger noe utover det.

Én ting å være klar over på `PUT /resource/{id}`: hvis ressursen deklarerer maskinporten-scopes, kjører `MaskinportenSchemaAuthorizer` en ekstra sjekk på at tokenet har riktig `consumer_prefix` for de scopene, og svarer 401 hvis ikke. Det gjelder også POST-varianten vi alt treffer, så det er bare et hensyn hvis testen begynner å sette maskinporten-scopes på ressursen den lager.

Del av #473

Start with create-resource-and-policy.js and inspect the unused ResourceUpdateResource, ResourceUpdatePolicy, update-resource.js, and update-policy.js files. Follow the existing authorization and response-checking pattern, then clarify whether the fixture is seeded or created on demand and whether it remains permanent. Done means coverage for PUT /resource/{id}, POST /resource/{id}/policy, and PUT /resource/{id}/policy with verified updates.

Written by the indexing model from the issue text.