Test POST /resource/bysubjects

**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.

Endepunktet tar en liste med subjekter og svarer med hvilke ressurser hvert subjekt har rettigheter i. Det er den motsatte oppslagsretningen av `/policy/subjects`, og det er anonymt.

Clienten `ResourceGetResourcesBySubjects` og byggeblokken `get-resources-by-subjects.js` finnes, og byggeblokken importeres ikke.

Testen bør opprette en ressurs med en policy som gir en kjent rolle tilgang, slå opp den rollen og sjekke at ressursen er med i svaret. Det gir en assertion som faktisk henger sammen, i motsetning til å slå opp en tilfeldig rolle og bare telle treff. Et tomt eller ukjent subjekt bør gi et tomt resultat og ikke en feil.

Åpent spørsmål: hvor lang tid det tar fra en policy er lastet opp til subjektindeksen er oppdatert. Hvis oppslaget ikke er umiddelbart trenger testen enten en ventestrategi eller en ressurs som er seedet fra før.

Scope: ingen. `bysubjects` har ingen `[Authorize]`, og `ResourceController` har ikke noe på klassenivå (`src/Altinn.ResourceRegistry/Controllers/ResourceController.cs` på main), så oppslaget er anonymt selv om det er en POST. Å seede ressursen og policyen krever `altinn:resourceregistry/resource.write` eller `resource.admin`.

Del av #473

Start with the existing ResourceGetResourcesBySubjects client and the unimported get-resources-by-subjects.js building block. Check ResourceController.cs to confirm the endpoint is anonymous, then determine whether the resource and policy are seeded or created once and whether indexing needs a wait strategy. Done means a known-role lookup returns the permanent resource, while empty or unknown subjects return an empty result without error.

Written by the indexing model from the issue text.