[Implementation - Admin] Landing Page for April Release

#### Description:

Build an admin landing page that serves as the primary entry point for all authenticated staff. The page uses progressive disclosure all authenticated users see search and basic navigation; users with elevated roles see additional metrics.

- Activity search bar

For the April release we will have the Admin user drill down from activity first then products then date.

#### Acceptance Criteria:

Given I am a government staff (Admin) user
When I go into the Admin system
Then I can see a landing page with an activity search bar

#### Development Checklist:

- [ ] All authenticated users see quick-nav cards linking to Inventory, Sales, and Reports
- [ ] All authenticated users see basic stat cards: today's reservation count and upcoming active activity count
- [ ] A superadmin user additionally sees an admin metrics section with system-wide counts and a Feature Flags shortcut
- [ ] Users with no role or no authentication see only a welcome screen and login prompt
- [ ] The admin metrics section is absent from the DOM entirely for non-admins (not just visually hidden)
- [ ] The AuthService exposes a synchronous role signal so widgets don't trigger async role checks per component

#### Dependencies

- Blocked by
- Blocking

**Relevant documentation as reference**
[Confluence - Admin Requirements](https://apps.nrs.gov.bc.ca/int/confluence/pages/viewpage.action?pageId=275678059)
[Data Model](https://github.com/bcgov/reserve-rec-api/wiki/Data-Model)

**Definition of Ready**

- [ ] Acceptance criteria are included
- [ ] Wireframes are included (if applicable)
- [ ] Design / Solution is accepted by Product Owner (if applicable)
- [ ] Dependencies are identified (technical, business, regulatory/policy)
- [ ] Story has been estimated (under 13 pts)

**Definition of Done**
- In progress:
- [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- [ ] UI meets accessibility requirements
- [ ] Unit tests are written
- [ ] Work is traceable in GitHub
- [ ] PR linked to ticket number
- [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
- Code review:
- [ ] Code is peer reviewed and has passed CI/CD tests
- QA:
- [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- [ ] Code is potentially shippable to the production environment
- [ ] Functional features have been tested and passed by QA
- [ ] UI components tested by designer
- [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
- PO Review:
- [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- [ ] Reviewed and approved by Product Owner

**Security Validation Checklist**
- Security-focused Peer Review:
- [ ] Reviewer explicitly considers abuse cases, privilege boundaries, and insecure patterns.
- Static Analysis Passed:
- [ ] Security linting tools (e.g., Bandit, ESLint plugins, SonarQube) executed and cleared
- Rate Limiting & Bot Defenses Verified:
- [ ] Anti-automation strategies (e.g., throttling, CAPTCHA/Turnstile, scoring) tested and confirmed.
- Threat Model Completed:
- [ ] Developers have identified potential attack vectors (e.g., spoofing, privilege escalation, data leakage), documented mitigations, and validated that defenses align with system goals and fairness principles.

#### Notes:
- Single page with @if gated sections per role tier (not separate routes/views per role). Role
checks are reactive (Angular signals from AuthService) so adding new roles in future sprints requires no routing
changes only new conditional blocks

Start with the admin application's single-page entry point and the AuthService role-signal design described in the issue. Review the acceptance criteria and development checklist before identifying the existing components and data sources for navigation, reservations, activities, metrics, and feature flags. Done means role-appropriate sections render, unauthorized metrics are absent from the DOM, accessibility and unit tests pass, and the acceptance criteria are verified.

Written by the indexing model from the issue text.