feat: render side-loaded menu entries between Home and Account (#48)

[andregoepel]

Closes #48.

What

The host-contributed nav component (Layout.AdminMenu <DynamicComponent>) was rendered inside the AuthorizeView Roles="Administrator" block, above the Administration group — so it only showed for admins, near the bottom. It now renders immediately after Home and before the Account group, for all users.

New order: Home → side-loaded entries → Account → Administration.

The contributed component is responsible for gating any role-specific entries (e.g. with its own AuthorizeView), as noted in the updated XML doc.

Rename (per the issue's note)

Since the entries are no longer administrator-scoped, AppFoundationLayoutOptions.AdminMenu is renamed to Menu. To avoid breaking existing hosts (e.g. andregoepel.dev), AdminMenu is kept as an [Obsolete] forwarding alias:

public Type? Menu { get; set; }

[Obsolete("Renamed to Menu. …")]
public Type? AdminMenu { get => Menu; set => Menu = value; }

NavMenu reads Layout.Menu, so there's no obsolete-usage warning in the foundation; a consumer still setting AdminMenu compiles (with a deprecation warning) and behaves identically.

Tests

AppFoundationLayoutOptionsTests verifies the AdminMenu ↔ Menu forwarding both ways.

Verification

• dotnet build -c Release — 0 errors, 0 warnings.
• dotnet test -c Release — 88/88 (1 new).

Note

There's no bUnit test for NavMenu positioning (rendering it needs IQuerySession/SetupCompletion, IIdentityFeatureProvider, auth state, and JS interop — the repo doesn't test it today), so the ordering is verified by the markup change. Happy to add a heavier component test if you'd like coverage there.