[Bug]: Table writes fail (HTTP 500) for entities defined in a linked `data-source-files` config

## When

Using a multi-database setup where a root config links a second database config via `data-source-files`:

```powershell
# Root config (database 1)
dab init --database-type mssql --connection-string "@env('DAB_SQL_DB1')" --host-mode Development -c dab-config.json
dab add Db1Orders --source dbo.Orders --permissions "anonymous:*" --source.type table -c dab-config.json

# Linked config (database 2)
dab init --database-type mssql --connection-string "@env('DAB_SQL_DB2')" --host-mode Development -c dab-config-db2.json
dab add Db2Customers --source dbo.Customers --permissions "anonymous:*" --source.type table -c dab-config-db2.json

# Link them
dab configure --data-source-files dab-config-db2.json -c dab-config.json

dab start -c dab-config.json
```

Then send a write to a **table entity that is defined in the linked file** (`dab-config-db2.json`):

```http
POST /api/Db2Customers
Content-Type: application/json

{ "Name": "test" }
```

## Expected

The insert succeeds and returns HTTP 201 with the created row, the same as an equivalent table entity defined in the root config. Table writes should work regardless of whether the entity's data source is in the root config or in a linked `data-source-files` config.

## Actual

The request returns HTTP 500 with a generic error:

```json
{
"error": {
"code": "UnexpectedError",
"message": "While processing your request the server ran into an unexpected error.",
"status": 500
}
}
```

The server log shows a `KeyNotFoundException` keyed by the entity name, thrown in the SQL mutation/insert path:

```text
System.Collections.Generic.KeyNotFoundException: The given key 'Db2Customers' was not present in the dictionary.
at Azure.DataApiBuilder.Core.Resolvers.BaseQueryStructure..ctor(...)
at Azure.DataApiBuilder.Core.Resolvers.SqlInsertStructure..ctor(...)
at Azure.DataApiBuilder.Core.Resolvers.SqlMutationEngine.PerformMutationOperation(...)
```

## Scope / Root cause (confirmed by test)

The failure is **positional**, not database- or table-specific. Swapping the topology proves it — the *same table* behaves differently based only on which config file it lives in:

| Table | In root config | In linked `data-source-files` config |
|-------|----------------|--------------------------------------|
| `dbo.Categories` | POST succeeds (200/201) | POST fails (500) |
| `dbo.Category` | POST succeeds (200/201) | POST fails (500) |

Additional observations:
- **Reads** (`GET`) work for linked-file entities.
- **Stored procedures** in linked files work (they use the `execute` path, not the table-mutation path).
- Only **table mutations** (`POST`/`PUT`/`PATCH`/`DELETE`) on linked-file entities fail.
- `dab validate` passes and reports REST paths for all entities across both files.

## Impact

In a multi-database DAB instance, tables in any linked (non-root) database are effectively read-only. Only the root database supports table writes.