Add a unit test suite and coverage reporting

### Current Behavior

Many libs are out of date and need to be updated. A good test coverage will bring a bit confidence in supporting mirgration.
There is no test runner configured, no specs, and no CI job that would catch a regression in the code the whole UI depends on.

Practically, this means:
- Behavior can only be verified by hand against a running instance and an API server.
- Pure logic in `src/shared/` and `src/mixins/` is unverified. This includes code where a silent regression has real consequences — `isUrlSaveForRedirect()` in `src/shared/utils.js` is an open-redirect guard, and `hasPermission()` in `src/shared/permissions.js` gates what the UI exposes to a user.
- `src/shared/common.js` contains a number of formatters that build HTML strings and rely on `xss-filters` for escaping. There is nothing asserting that the escaping stays in place.
- The `lint.yaml` workflow runs Prettier, ESLint and the i18n check, and `ci-build.yaml` runs a build, but nothing runs tests. A pull request cannot be gated on behavior.
- There is no coverage signal, so it is not visible which parts of the codebase are unverified or whether a change makes that worse.

### Proposed Behavior

Add a unit test suite to the frontend, wired into CI as a blocking check.

Specifically:

1. **A test runner suited to the stack.** Jest with jsdom plus `@vue/test-utils`, since the project is Vue 2 with Vue CLI. Exposed as `npm test`, `npm run test-watch` and `npm run test-coverage`.

2. **Specs for the code most worth protecting first**, rather than chasing a coverage number:
- `src/shared/` — the formatters, comparators, permission helpers and URL guards.
- `src/mixins/` — starting with `permissionsMixin` and `filterPillsMixin`.
- The filter pill components under `src/views/components/`, which carry non-trivial state and emit logic.

3. **Coverage reporting with an enforced floor.** Report to `coverage/` including `lcov.info` so the numbers can be consumed by external tooling later, and set thresholds at the measured baseline so coverage cannot silently regress. Files that have no specs yet should stay inside the measured scope so that the remaining gap is visible rather than hidden.

4. **A CI job that runs the suite** on the same triggers as the existing lint workflow, publishing the coverage report as an artifact.

5. **Documented conventions**, so that later contributions are consistent: where specs live, how they map to `src/`, how to mount components, and how to deal with the parts of the app that assume a webpack build.

**Why:** the contributing guidelines state that *"new functionality should have corresponding tests added to the existing test suite if possible"*, which is not currently actionable because no such suite exists. Establishing one makes that expectation enforceable, gives reviewers a way to confirm a change is safe without running the app by hand, and protects the security-relevant helpers above from silent regressions.

Two constraints worth stating up front, since they shape the implementation:

- Some modules cannot be loaded under Jest as-is. `src/i18n/index.js` uses webpack's `require.context` and performs an HTTP request at import time, and `src/shared/utils.js` imports `flexver/dist/module`, which is ESM. Both need handling in the Jest configuration rather than changes to `src/`.
- The initial suite should not modify production code. Where existing behavior is surprising, the tests should document it and any correction should be proposed separately.

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/main/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/frontend/issues) for whether this enhancement was already requested

Start by inspecting package.json, the existing lint.yaml and ci-build.yaml workflows, and the named paths under src/shared/, src/mixins/, and src/views/components/. Confirm how the Vue 2 frontend is built and where configuration belongs for the modules noted in the issue. Done means npm test, npm run test-watch, and npm run test-coverage are available, targeted specs run in CI with coverage artifacts and thresholds, and testing conventions are documented.

Written by the indexing model from the issue text.