fix(ui): restore the top nav on the enterprise pages (#1636)

[dolho]

Summary

/enterprise and /enterprise/audit rendered no top nav — the user landed with no way back to the platform except the browser's back button.

Root cause is as the issue describes: Trinity has no global chrome. App.vue renders only <router-view>, so every authenticated view mounts NavBar itself. The enterprise views never did, so the chrome silently vanished on those routes.

Review with git diff -w. The real change is 21 added lines, 0 deletions. Wrapping each template re-indents its body, which inflates Audit.vue to ~1266 lines of pure whitespace churn.

Changes

• views/enterprise/Index.vue, views/enterprise/Audit.vue — wrap the existing centred container in the house layout (min-h-screen shell → NavBar → content), matching Settings.vue / Templates.vue. The original p-6 max-w-* containers are untouched, so spacing is unchanged and there's no double padding.
• router/index.js — document the /enterprise/client-portal intent (see below).

Active highlight needed no change. NavBar's Enterprise link already keys off $route.path.startsWith('/enterprise'), so it highlights correctly on both routes once NavBar renders.

/enterprise/client-portal deliberately keeps NO NavBar, and the route comment now says so rather than leaving it ambiguous: it's a client-facing surface, not an operator page — platform nav would offer a client links they can't use. It sits alongside /portal and /m. (Ambiguity was the actual bug here: the missing comment is why a reader couldn't tell "standalone by design" from "same defect as its siblings".)

Scope

The issue floats hoisting NavBar into App.vue behind a meta.standalone opt-out — "unless it's the cheaper fix". It isn't: 7 views render NavBar today, so hoisting means touching ~12 files, adding meta.standalone to every standalone route, and risking double-nav on every authenticated page. Left as the follow-up the issue describes.

Verification

Production vite build succeeds, and the built output confirms the wiring rather than just the intent:

• Index-*.js (contains enterprise-landing) → references NavBar ✅
• Audit-*.js (contains audit-dashboard) → references NavBar ✅
• Portal-*.js, ClientPortal-*.js, MobileAdmin-*.js → no NavBar ✅ (standalone surfaces unregressed, AC Setup improvements #5)

Both wrappers use the same min-h-screen bg-gray-100 dark:bg-gray-900 shell as the rest of the platform, so dark mode inherits the existing behaviour (AC #7).

Not visually confirmed in a browser — worth stating plainly. This repo's docker-compose.override.yml deliberately repoints the frontend dev server at the trinity-portal-cleanup worktree ("so Vite serves the old-client-portal cleanup at localhost:8001"), so localhost:8001 doesn't serve this branch, and I didn't want to disturb that setup. Verification here is build + bundle-level. A reviewer with the override reverted (docker compose up -d frontend) can eyeball /enterprise and /enterprise/audit in a few seconds.

Interaction with #1637

PR #1637 removes /enterprise/client-portal entirely. If it lands first, the route comment added here disappears with the route — no conflict in substance, and the Index.vue/Audit.vue fixes are independent of it.

Test Plan

• vite build succeeds (production config)
• Enterprise chunks reference NavBar; Portal/ClientPortal/MobileAdmin chunks do not
• Existing p-6 max-w-* containers unchanged — no double padding
• Reviewer: eyeball /enterprise + /enterprise/audit light/dark with the frontend mount pointed at this branch

Closes #1636

[dolho]

[vybe]

Validated via /validate-pr: mechanical NavBar mount on the two operator-facing enterprise pages (Audit, Index) — the diff is a wrap+re-indent, verified no template content changed; the client-portal route's standalone status is documented as deliberate. Security battery clean. Approving.