[Story]: Component test harness for apps/web

### Story Statement

As a developer changing `apps/web`, I want a component test harness so that I can assert a
component's rendered behaviour in CI instead of relying on a manual click-through.

### Real Intent

`apps/web` has **no component testing at all** today — no runner, no config, no test script:

```text
$ ls apps/web/vitest.config.* apps/web/jest.config.* -> no matches
$ grep '"test"' apps/web/package.json -> no test script
$ find apps/web -name "*.test.tsx" -> nothing
```

This is not a gap that shows up as a failing build; it shows up as stories that ask for a component
test and cannot get one. It has now happened twice on the same pattern:

- #516 asked for *"Component test for the embed with/without `NEXT_PUBLIC_GRAFANA_URL` set"*.
[PR #594](https://github.com/ADORSYS-GIS/lightbridge-code-intelligence/pull/594) could not
provide it.
- The component it mirrors, `run-logs-embed.tsx` (#479/#480), is untested for the same reason.

Both components have the same shape: a branch on an environment variable, then a URL built from
several pinned parameters. That is precisely what a component test is cheap and good at, and
precisely what a click-through verifies slowly and forgets to re-verify later. PR #594 has already
had to change that URL twice — once to pin `var-model`, once to pin the range — with no automated
check that either landed.

Filed so that #516 is not closed with its stated test expectation silently unmet.

### Background and Context

`apps/web` is a Next.js app in a pnpm + Turborepo monorepo. Other workspaces have their own test
stories; `apps/web` was never given one, and the repo-wide `turbo run test` therefore has nothing to
run for it. The two Grafana embeds (`components/runs/run-logs-embed.tsx`,
`components/repos/repo-analytics-embed.tsx`) are the immediate motivation, but the harness is the
deliverable — not tests for those two files specifically.

### Source of truth (links)

Epic #493 (apps/web investment). Immediate driver: #516 and its
[PR #594](https://github.com/ADORSYS-GIS/lightbridge-code-intelligence/pull/594), whose review
recorded the gap. Pattern under test: ADR-0102 (`d-solo` Grafana embed).

### Acceptance Criteria

#### Functional

- [ ] Given a developer runs the workspace's test command, when `apps/web` has component tests,
then they execute and report pass/fail.
- [ ] Given the monorepo's `turbo run test`, when it runs, then `apps/web`'s tests are included
rather than silently skipped.
- [ ] Given CI on a pull request, when `apps/web` tests fail, then the check fails.
- [ ] Given `RunLogsEmbed` and `RepoAnalyticsEmbed` as the first subjects, when
`NEXT_PUBLIC_GRAFANA_URL` is unset, then the test asserts the fallback renders and **no
`` is emitted**; and when it is set, then the test asserts the generated `src`
contains every pinned parameter (`panelId`, `var-repo` / `var-task_id`, `var-model`,
`from`/`to`, `kiosk`).

#### Non-Functional

- [ ] The runner is consistent with the monorepo's existing tooling rather than a second
independent choice — check what other workspaces use before picking.

### Out of Scope

- Retro-fitting tests across all of `apps/web`. The two embeds are the proof the harness works; the
rest arrives with the code that touches it.
- End-to-end / browser tests. This is component-level only.
- Changing any component's behaviour.

### Dependencies and Blockers

None. Can land independently of #516 and PR #594.

### Assumptions

- The monorepo already has a test runner in use elsewhere that `apps/web` can adopt rather than
introducing a new one — verify before choosing, do not assume Vitest.
- React Server Components complicate component testing: both embeds are Server Components (no
`"use client"`), so they read `process.env` at render on the server. Confirm the chosen runner
can render them, or scope the first tests to the pure URL-building logic. **This is the main
unknown in the story and should be settled before committing to a runner.**

### Implementation Notes

Deliverable is the harness plus the first tests that prove it runs in CI. Keep the initial surface
small; the point is the wiring, not coverage.

### Test Expectations

The story's own deliverable is tests, so the evidence is the CI run: a green `apps/web` test job,
plus a demonstration that it goes red when an assertion is broken on purpose.

### Verification evidence

Not yet started — to be added by the implementer before this story is closed.

### Human accountable owner

@leghadjeu-christian

### AI Usage Declaration

Drafting this story. The gap itself was found by Claude (Claude Code) while reviewing PR #594
against #516's stated test expectation; the three `find`/`grep` results quoted above were run
against the repo, not assumed.

### Human verification completed

- [ ] I checked the story against the source of truth
- [ ] I confirmed the acceptance criteria
- [ ] I reviewed the implementation approach
- [ ] I am the accountable owner and accept responsibility for this story.

_AI-drafted for review; the final accountability checkbox is intentionally left unticked._