Scope Copilot's instructions to one directory with an applyTo instructions file

# Path-scoped custom instructions for GitHub Copilot
# Save as .github/instructions/tests.instructions.md — files under .github/instructions/ apply only to the paths
# matched by their applyTo glob, layered on top of .github/copilot-instructions.md rather than
# replacing it, for any Copilot Chat request or coding-agent session touching a matching file.

---
applyTo: 'tests/**/*.spec.ts'
---

## Why this directory gets its own rules
Tests under tests/ use Vitest with a custom fixture loader, a different pattern than the Jest conventions the rest of the repo's older suites still follow.

## Rules that apply only here
- Import the shared fixture loader from tests/fixtures/index.ts instead of building test data inline.
- Never use jest.mock — this directory has no Jest dependency at all.

## Where this deliberately differs from the repo-wide instructions
The repo-wide instructions say to colocate tests next to components; this directory is the deliberate exception for integration tests that span multiple components.
State the difference explicitly rather than leaving Copilot to notice a contradiction and guess
which file wins — both files are added to context together for a matching request, so an unstated
conflict is a coin flip, not a resolved rule.

## A change that should have been caught by this file but was not
A generated test in this directory once called jest.mock directly, which failed at runtime since Jest is not installed here at all.
If a real instance already happened, name it — a rule justified by a concrete miss is easier to
trust than one written speculatively, and it gives Copilot a worked example of the exact mistake
this file exists to prevent, in a form more specific than the rule statement alone.

## Keeping the glob honest
Test the applyTo glob against the actual file tree before relying on it, not just against the one
file you had in mind when writing it — a glob written to match 'tests under this directory' can
just as easily match an unrelated fixtures folder that happens to share a path segment, silently
applying a rule meant for one kind of file to a completely different one nearby. If the directory
this file governs gets restructured later, this file has to move or its glob has to be rewritten
in the same change — an instructions file whose glob no longer matches anything real is worse than
a missing one, because it looks like coverage exists when it does not.

## If more than one instructions file matches the same file
Two different applyTo globs can both match a single file if their scopes overlap even in part —
say directly whether that is expected and, if so, which file's rule should be treated as more
specific when they seem to disagree, since Copilot has no way to infer an intended priority
between two files that were each written independently of the other.