trios/agent-server/apps/agent/entrypoints/app/login/LoginPage.tsx exports one symbol and no test names any of them

Measured on origin/feat/queen-supervisor, the tree a bee clones:

$ git show origin/feat/queen-supervisor:trios/agent-server/apps/agent/entrypoints/app/login/LoginPage.tsx | wc -l
228

exports: LoginPage
searched: every *.test.ts under apps/server/tests, concatenated
found:    none of these identifiers appears anywhere in that corpus

The weak version of this claim would be "there is no LoginPage.tsx.test.ts",
and it would be worthless: 144 of 260 source files have no test of the same name,
and most of them are covered perfectly well by suites named after something else.
queen-tick.ts is exercised by a dozen queen-*.test.ts files and has no test
of its own name. So the question asked here is the stronger one - whether any
exported identifier of this module is mentioned anywhere in the test corpus at
all - and by that measure only nine modules in the repository qualify. This is
one of them.

Untested is not the same as broken. This asks for the first suite, not a rewrite:
the behaviour that already exists, pinned, so the next change to this file has
something to fail against.

User Scenarios & Testing

User Story 1 - The module's contract is pinned as it stands today (P1)

Acceptance Scenarios:

1. Given each exported symbol,
   When the suite runs,
   Then at least one assertion exercises it, and the suite names the symbol
   it is covering so a reader can map assertions to exports.
2. Given the module's behaviour as it is today,
   When the suite runs against the unmodified source,
   Then it passes. A first suite that requires changing the subject is a
   redesign wearing a test's clothes.
3. Given a deliberately broken copy of the subject,
   When the suite runs against it,
   Then it fails. A suite never shown failing has not been tested.
4. Given the suite,
   When it runs,
   Then it needs no network, no database and no container.

User Story 2 - What could not be pinned is named (P2)

Acceptance Scenarios:

1. Given an export whose behaviour cannot be exercised without a live
   dependency,
   When the suite is read,
   Then that export is listed in a comment with the dependency that blocked
   it, rather than silently omitted. An untested export inside a file that now
   looks tested is worse than one in a file that plainly is not.

Requirements

• FR-001: The subject MUST NOT be modified. If a symbol cannot be tested without changing it, say so in the comment required above and leave it.
• FR-002: The suite MUST run under bun test in an existing group and MUST NOT require a database, a container or the network.
• FR-003: Every assertion MUST test observable behaviour, not the shape of the implementation. A test that asserts a function calls another function pins the code rather than the contract.
• FR-004: The bee MUST demonstrate the suite failing against a deliberately broken copy before showing it passing, and quote both runs.
• FR-005: No existing test may be modified or weakened.

Success Criteria

• bun test trios/agent-server/apps/agent/entrypoints/app/login/LoginPage.test.ts passes, and its raw stdout is quoted in the report, unedited and unsummarised.
• Every one of the 1 exported symbols is either exercised by an assertion or listed in a comment with the dependency that prevented it; the report quotes grep -c 'it(' trios/agent-server/apps/agent/entrypoints/app/login/LoginPage.test.ts and its raw output, and the two counts sum to 1. The command MUST NOT name or enumerate the specific items it counts.
• A failing run against a deliberately broken copy of the subject is quoted, raw and unedited, alongside the passing one - a suite never shown failing has not been tested.
• git diff --name-only is quoted raw and does not list trios/agent-server/apps/agent/entrypoints/app/login/LoginPage.tsx.
• The suite registers under a describe named LoginPageTsxContract; that identifier appears nowhere in the tree today.

Boundary

trios/agent-server/apps/agent/entrypoints/app/login/LoginPage.test.ts