Modifies the `/api/v1/auth/request-code` route handler to parse an
optional `is_dashboard_login` boolean field from the request body.

This flag is then passed to the `AuthService.initiateEmailSignIn`
method, enabling it to trigger the appropriate validation logic for
either a standard user-facing app sign-in or a restricted dashboard
login.

Refactors the `AuthService.completeEmailSignIn` method to be
context-aware based on an `isDashboardLogin` flag.

- The method now accepts `isDashboardLogin` instead of `clientType` and
  `currentAuthUser`.
- If `isDashboardLogin` is true, the method only attempts to find and
  log in an existing user. It will not create a new account.
- If `isDashboardLogin` is false, it performs the standard
  sign-in/sign-up flow for the user-facing app.
- A special case is added to grant 'admin' role to a new user signing
  up with '[email protected]' for easier in-memory setup.
- The redundant logic for anonymous user account linking has been
  removed, as it is correctly handled by `completeLinkEmailProcess`.

Modifies the `/api/v1/auth/verify-code` route handler to parse an
optional `is_dashboard_login` boolean field from the request body.

This flag is passed to the `AuthService.completeEmailSignIn` method,
enabling it to trigger the appropriate verification logic for either a
standard user-facing app sign-in/sign-up or a restricted dashboard
login.

The handler is also simplified by removing the now-redundant logic for
passing the `authenticatedUser` to the service.

Removes the flawed logic that granted admin privileges to a user signing
up with a specific hardcoded email address. This was a security risk as
the service logic runs in all environments.

All new users created via the public API will now correctly and safely
be assigned only the 'standardUser' role. Privileged users like
administrators must be provisioned out-of-band (e.g., via data
fixtures), which is the correct and secure approach.

Creates a new data fixture file to seed an initial administrator user
with the email '[email protected]'.

This user is loaded into the in-memory repository on startup, providing
a pre-existing privileged account for development and testing of the
dashboard login flow. This is the correct, secure way to provision
initial admin users, removing the need for insecure logic in the public
API services.

Updates the documentation comments for `initiateEmailSignIn` and
`completeEmailSignIn` in the `AuthService`.

The new comments clearly explain the context-aware behavior based on the
`isDashboardLogin` flag, detailing the different validation logic for
the user-facing app versus the dashboard login. This improves clarity
for future development.

Updates the documentation comments for the `/request-code` and
`/verify-code` route handlers.

The new comments clearly explain the context-aware behavior driven by
the `is_dashboard_login` request body flag, detailing the different
logic for the user-facing app versus the dashboard.

Consolidates the two separate "Key Capabilities" points related to
authentication into a single, more concise entry.

This improves readability and removes redundancy while still effectively
highlighting the full scope of the authentication system, including both
standard user flows and the secure dashboard login.

Consolidates the "Robust Data Management" and "Flexible Data Sorting"
capabilities into a single, more comprehensive point. This removes
redundancy and improves the clarity of the feature list.