Feature request: declarative entity-grid nav pages (ResourceType for an entity's grid, no custom component)

## Summary

There is no declarative way to put an **entity's grid** on an application nav page. `Application.DefaultNavItems` can already express "this page is a Query" (`ResourceType: "Queries"`), but the equivalent for "this page is the grid for entity X" does not exist, so every application that wants an entity list must ship an Angular component to do it.

## What already works, and what doesn't

Trying to build an application whose nav pages are entity grids, using only metadata:

| Approach | Result |
|---|---|
| `ResourceType: "Queries"` + `RecordID` | ✅ works — runs a `Query`, but that is not an entity grid |
| `ResourceType: "Records"` | ❌ `RecordResource` renders `` — one record, not a list |
| `ResourceType: "User Views"` + `RecordID` | ❌ needs a saved `UserView` record; a System-owned shared view throws `You do not have permission to view this view`, because `CalculateUserCanView()` checks owner then `ResourcePermissionEngine` and never reads `IsShared` — and MJ ships **zero** `ResourcePermission` rows |
| `NavItem.Route` pointing at `view/dynamic/` | ❌ clicking the nav item does not navigate; the rail renders but `Route` appears not to be honoured for nav items |
| `ResourceType: "Custom"` + `DriverClass` | ✅ the only working answer — requires an Angular component |

For context on how universal that last row is: across all **26** applications in a stock install, **all 81** nav items use `ResourceType: "Custom"`. Not one uses `User Views`, `Records`, `Lists`, `Dashboards` or `Queries` from a nav item.

## The ask

A first-class resource type for "the grid for this entity", configured on the nav item, e.g.:

```json
{
"Label": "Animals",
"Icon": "fa-solid fa-paw",
"ResourceType": "Entity Grid",
"Configuration": { "Entity": "MJ: Animals" }
}
```

rendering `` with its normal behaviour — sort, filter, page, click into a record. `mj-entity-viewer` already accepts `EntityName` as a plain string input, so the rendering side needs nothing new; what is missing is a registered resource wrapper plus the `ResourceType` row.

A minimal implementation is roughly the existing `RecordResource` with `` swapped for ``:

```ts
@RegisterClass(BaseResourceComponent, 'EntityGridResource')
@Component({
standalone: false,
selector: 'mj-entity-grid-resource',
template: ``
})
export class EntityGridResourceComponent extends BaseResourceComponent { /* ... */ }
```

## Why it is worth having

An application that is *just* entity grids plus a couple of queries is a common shape — CRUD over a handful of tables is the starting point for most apps built on MJ. Today that shape cannot be expressed in metadata, so every such app carries boilerplate Angular whose only job is to forward an entity name to a grid MJ already ships.

It would also make "add an app to Explorer" a genuinely metadata-only operation: register the application, declare the nav rail, file the entities, done. That is a strong story for MJ's metadata-driven architecture, and it is currently one resource type short.

Alternatively, if `NavItem.Route` is *intended* to work and simply isn't reaching the router, fixing that would achieve much the same thing — `resource/view/dynamic/:entityName` already exists as a route and is exactly the dynamic (no saved view) grid this asks for.

Start by tracing Application.DefaultNavItems and the existing RecordResource/BaseResourceComponent registration, then inspect how mj-entity-viewer is reached through resource/view/dynamic/:entityName. Compare adding an EntityGridResource with the NavItem.Route path. Done means a metadata-only nav item renders the entity grid with normal sorting, filtering, paging, and record navigation, without a custom Angular component.

Written by the indexing model from the issue text.