docs: add flaky test quarantine and remediation policy

[GoogilyBoogily]

Summary

• Add CONTRIBUTING.md with Test Stability, Quarantine & Remediation Policy
• Defines flaky test detection, quarantine via .skip, and 30-day remediation SLA

Test plan

• Verify CONTRIBUTING.md renders correctly on GitHub

[Copilot]

Pull request overview

Adds contributor documentation describing local dev/test commands and a policy for detecting, quarantining, and remediating flaky tests in this repository.

Changes:

• Introduces a new CONTRIBUTING.md with development + test instructions.
• Documents a flaky test quarantine workflow using .skip plus a tracking issue.
• Defines remediation expectations (30-day SLA, escalation after 14 days).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The statement that skipped tests are "excluded from coverage reporting" is inaccurate for the current Jest setup (collectCoverageFrom includes all src files). Skipping a test usually means less code gets executed and coverage can drop (and potentially fail the configured coverageThreshold). Please reword to reflect how coverage works here and what maintainers should expect when quarantining tests.

Suggested change

3. **Skipped tests are excluded from coverage reporting.** Since quarantined tests do not execute, their associated source code is not counted toward coverage metrics. This is expected and acceptable while the test is in quarantine.

3. **Skipped tests do not run, so coverage may decrease.** In this Jest setup, coverage reporting still includes the configured source files even when a quarantined test is skipped. Because the skipped test no longer exercises its code paths, overall coverage can drop and may cause the configured `coverageThreshold` to fail. Maintainers should expect this when quarantining a test and either remediate the test promptly or make any necessary coverage-related follow-up as part of the quarantine plan.

[Copilot]

Minor grammar: "Flaky tests are any test" should be rephrased (e.g., "A flaky test is a test..." or "Flaky tests are tests...") to read correctly.

Suggested change

	Flaky tests are any test that passes and fails intermittently without code changes (this could be due to things like timeouts, inconsistent return values, poor assertions, etc). Flaky tests erode confidence in the test suite and slow down development. This section defines how we detect, quarantine, and remediate them.
	A flaky test is a test that passes and fails intermittently without code changes (this could be due to things like timeouts, inconsistent return values, poor assertions, etc). Flaky tests erode confidence in the test suite and slow down development. This section defines how we detect, quarantine, and remediate them.

[Copilot]

The GitHub Help URL here is deprecated (help.github.com). Please update the link to the current docs.github.com page for creating a pull request so it doesn't break or redirect unexpectedly.

Suggested change

	- [Create a pull request](https://help.github.com/articles/creating-a-pull-request)
	- [Create a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)

[Copilot]

This repo doesn't appear to use Playwright (no dependency/config found). Mentioning Playwright retries here is likely confusing—either remove the Playwright reference or replace it with the actual integration/e2e test tooling used in this project.

Suggested change

	- **Automatic retries**: Jest unit tests can be configured to automatically retry on failure via `jest.retryTimes()`. Playwright integration tests (where applicable) have retries configured per-project. A test that fails once but passes on retry can be considered as potentially flaky.
	- **Automatic retries**: Jest unit tests can be configured to automatically retry on failure via `jest.retryTimes()`. A test that fails once but passes on retry can be considered as potentially flaky.

[codentacos]

👍 🧙