feat(#2114): expose viaRole on connection sub-connections

[Thuen]

Description

Adds a viaRole field to ConnectionDto, populated on sub-connections so the GUI can show why a party appears nested under another one.

In the issue's scenario the caller lists who has access to their own party. Regnskapshelten holds the access, and Janne Dagl shows up beneath it because she is daglig leder there. Until now the response said Janne was a sub-connection but not what made her one.

The plumbing already existed — ConnectionBaseQueryBuilder sets ViaRoleId on every key-role and client-delegation record, and ConnectionEntityEnricher already resolves it to a full Role. The value was simply dropped in the mapper. This change adds the field to the contract and maps it in ConvertSubConnectionsToOthers / ConvertSubConnectionsFromOthers.

Behaviour:

• Set only on sub-connections; top-level connections leave it null, as the issue asks.
• null when the relation carries no role, e.g. a plain main-unit hierarchy record.
• When a party reaches the same parent through several records, the first record that actually carries a via role wins, so a role-less hierarchy record cannot mask a key-role one.

Purely additive, so no existing consumer breaks. The frontend has viaRole on permissions today but not on connections, so nothing needs to change there until the GUI starts rendering it.

Note for review

A person can hold more than one key role in the same organisation (for example both dagl and styreleder). The issue asks for a single viaRole, so that is what this implements, and the second role is not surfaced. If @allinox wants all of them shown, adding a viaRoles list later is an additive follow-up.

Related Issue(s)

• Ønsker å få inn viaRole i GetConnection-endepunktet #2114

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

5 unit tests added to DtoMapperConnectionQueryTest, covering the issue's key-role scenario end to end through ConvertToOthers, both sub-connection mappers, the null cases, and the masking case. Verified they are not vacuous: reverting the mapper change makes exactly the 3 positive tests fail. Full Altinn.AccessMgmt.Core.Tests unit suite green (the only local failures are integration tests that need Docker, which is not running here).

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

🤖 Generated with Claude Code

[howieandersen]

Liten og ryddig, og testene dekker maskeringstilfellet godt. En ting bør avklares før merge.

DtoMapperConnectionQuery.cs:150 og DtoMapperConnectionQuery.cs:200: c.FirstOrDefault(t => t.ViaRole is not null) er ikke deterministisk når samme part når forelderen gjennom flere records med ulik via-rolle, for eksempel en person som er både DAGL og LEDE i samme selskap. Da er det radrekkefølgen fra spørringen som avgjør hvilken rolle GUI-et viser, og den kan variere mellom kall siden enrich-spørringen ikke har noen ORDER BY. Forslag: velg deterministisk innenfor gruppen, for eksempel OrderBy på rollekode før FirstOrDefault, eller prioriter KeyRole-records foran klientdelegering om det er semantikken dere er ute etter. Si i så fall også i XML-doc-en hvilken rolle som vinner når det finnes flere.

Ellers ingenting. Kontraktendringen er additiv og følger samme mønster som PermissionDto.