[Bug]: Non-anonymous role permissions break queries selecting sibling nested relationship lists (Object/Array error in ExecuteListField)

### What happened?

On DAB 2.0.8 (MSSQL, GraphQL), any query that selects **two or more sibling nested relationship lists** fails with:

```
System.InvalidOperationException: The requested operation requires an element of type 'Object', but the target element has type 'Array'.
at System.Text.Json.JsonElement.TryGetProperty(String propertyName, JsonElement& value)
at Azure.DataApiBuilder.Service.Services.ExecutionHelper.TryGetPropertyFromParent(...) ExecutionHelper.cs:line 350
at Azure.DataApiBuilder.Service.Services.ExecutionHelper.ExecuteListField(...) ExecutionHelper.cs:line 293
...
at HotChocolate.Authorization.AuthorizeMiddleware.InvokeAsync(IMiddlewareContext context)
```

**but only when the entities' permissions use a non-`anonymous` role.** With the identical config where every permission role is `anonymous`, the same query succeeds.

### Repro

Schema shape (SQL Server): `Organization 1-N OrganizationAddress N-M AddressType` and `Organization 1-N OrganizationEmail N-M EmailType` (junction/linking-object relationships).

```graphql
query {
organization_by_pk(id: "...") {
id
addresses { items { id addressTypes { items { id } } } }
emails { items { id emailTypes { items { emailTypeId } } } }
}
}
```

- Config A: all entity permissions `{"role": "anonymous", ...}` → **works** (any auth provider; also works when the request carries `X-MS-API-ROLE: authenticated` under Simulator).
- Config B: byte-identical except every `"role": "anonymous"` replaced with `"role": "authenticated"` (Simulator provider, request sent with `X-MS-API-ROLE: authenticated`) → **fails** with the error above at path `organization_by_pk.addresses.items[0].addressTypes.items`.
- Selecting only ONE of the nested chains (only `addresses.items.addressTypes` OR only `emails.items.emailTypes`) works in both configs.
- Reproduces identically with the EntraID provider and a valid bearer token.
- The error also poisons the response data: the affected relationship resolves to `null` alongside the error.

### Analysis

When permissions use a non-anonymous role, Hot Chocolate attaches `AuthorizeMiddleware` to the DAB-generated fields (visible in the stack). That changes field execution from inline pure resolvers to the classic middleware pipeline with concurrent resolver tasks. DAB's pagination metadata is stashed in shared request `ContextData` under keys derived from root field name + path depth (+ relationship path suffix) — see `ExecutionHelper.GetMetadata` / `SetNewMetadataChildren`. With two sibling nested subtrees resolving concurrently, the lookup for the second-level connection (`addressTypes`) misses (or reads the sibling's entry), falls back to `PaginationMetadata.MakeEmptyPaginationMetadata()`, so the connection wrapper is not applied and the child `items` resolver receives a raw JSON array where it expects the connection object.

The relevant code is unchanged on `main` as of this report, so the issue is not specific to 2.0.8.

### Impact

Role-restricted GraphQL (i.e., actually using DAB authorization — the reason auth exists) breaks on common list+junction selections, while fully-anonymous configs appear fine — so the bug surfaces exactly when hardening permissions.

### Version

- Data API builder 2.0.8 (container and CLI), SQL Server (Azure SQL DB), GraphQL runtime only (REST disabled).

Reproduce the query with sibling nested lists under anonymous and authenticated roles, then trace ExecutionHelper.cs, especially ExecuteListField, GetMetadata, and SetNewMetadataChildren. Check how concurrent authorized field execution affects pagination metadata lookup; done means the authenticated query returns both relationship lists without an Object/Array error or null data.

Written by the indexing model from the issue text.