Lag client og byggeblokk for GET /resource/changes og test den

Endepunktet gir en paginert strøm av ressurser som er endret, sortert etter endring, med en ugjennomsiktig `token` og en `limit` mellom 1 og 1000. Bare ressurser som har fått lastet opp en policy minst én gang er med, og hver ressurs opptrer høyst én gang, på plassen til sin siste endring.

Dette er den eneste operasjonen i registeret der ingenting finnes fra før: ingen client-metode i `ResourceClient`, ingen byggeblokk, ingen typer. Oppgaven er derfor større enn de andre, og omfatter en `ResourceChanges`-metode med en query-builder på linje med `ResourceUpdatedQueryBuilder`, en byggeblokk, og testen.

Testen kan følge `get-updated-resources.js` tett, siden pagineringen er den samme formen: hent en side med lav `limit`, sjekk formen på elementene, følg next-lenken og sjekk at neste side gir andre ressurser enn den forrige. En `limit` utenfor 1 til 1000 skal gi en valideringsfeil.

Åpent spørsmål: om testen kan sjekke at en ressurs den nettopp opprettet og ga policy dukker opp i strømmen. Det ville gjort testen langt sterkere enn en ren formsjekk, men det avhenger av hvor raskt strømmen oppdateres.

Scope: ingen. `changes` har ingen `[Authorize]`, og `ResourceController` har ikke noe på klassenivå (`src/Altinn.ResourceRegistry/Controllers/ResourceController.cs` på main), akkurat som `updated`. Hvis testen skal sjekke at en ressurs den selv har opprettet dukker opp i strømmen, trenger arrange-steget `altinn:resourceregistry/resource.write` eller `resource.admin`.

Del av #473

Start with get-updated-resources.js and ResourceUpdatedQueryBuilder, then trace ResourceClient and the resource-building-block patterns. Add the ResourceChanges client method, query builder, building block, and test for pagination, distinct resources, element shape, and invalid limits. Treat the newly created resource check as optional pending propagation speed.

Written by the indexing model from the issue text.