docs(governance): add end-of-life, support, compatibility, and data residency policies

[sadeeq6400]

Summary

Adds four lifecycle policies under Governance/policies/, closing the governance gaps tracked in #1493, #1494, #1495, and #1496.

Policy	Closes	Covers
END_OF_LIFE.md	#1493	How EOL is decided and announced, support reduction stages, migration guidance
SUPPORT.md	#1494	Support channels and scope, response expectations, out-of-scope items
COMPATIBILITY.md	#1495	Supported versions, window length, drop criteria
DATA_RESIDENCY.md	#1496	Where data may be stored, transfer restrictions, exception process

What these documents add

End of life as a decision, not a lapse. End of life is triggered by a recorded maintainer decision with a stated approver, not by a date passing. A feature proposed for retirement needs evidence of low use or high cost — and where the project has no usage data, the issue must say so rather than assert the feature is unused. "No end of life by silence": anything still shipped is still maintained, or it is brought to an explicit decision.

Five support reduction stages. Active → Maintenance → Deprecated → Frozen → End of life, each with a minimum interval and a defined commitment. Stages may not be skipped. Frozen is explicitly not an abandonment: if a platform or provider removes something the app depends on, that is a critical defect and is fixed under the patch policy even during Frozen. Every announcement must state five things, and one of them is the migration path — "we are removing this" without "use this instead" transfers the whole cost to the user. Migration guidance is written before the Deprecated stage begins.

Support with a written scope. Response expectations are given in business days per request type, distinguishing acknowledgement from first substantive response from update cadence while unresolved, with each defined. Acknowledging promptly and then going quiet for months is named as the failure mode the policy exists to prevent. The out-of-scope table gives a reason for every entry — including self-hosted deployment, legal advice, and features that conflict with the project's non-goals — so declining is a decision rather than a deferral. Nothing promises a fix, and the policy says so explicitly.

Compatibility windows with evidence. The supported-version table is verified against the repository rather than asserted: iOS 15.1 and Android 7 per app.config.ts, Expo SDK 54 and React Native 0.81 per package.json, and the Node version CI uses. Each drop criterion names the evidence it requires — a vendor announcement paired with sub-1-percent session data over a stated 90-day period, a documented workaround attempt — and a criterion being met only starts the notice period, it does not drop the version. Meeting the criterion and removing support are separate changes.

Data residency. Storage location per data category, with backups and disaster-recovery copies required to stay in the same region — separating them for durability does not change residency. Transfers are restricted to three justified categories; a provider that replicates globally by default is treated as a transfer requiring the same approval as a deliberate one. Telemetry is not exempt: crash reports and analytics qualify only because they carry no personal data, which is a condition of the telemetry policy rather than a waiver. The exception process requires the privacy policy to be updated before a residency change takes effect — a residency change is never internal-only. Where legal obligations make the approved location unavailable, the answer is to change the feature or the provider, not to store the data anyway and record an exception.

Notes for reviewers

• Boundaries with existing governance are deliberate. The Security Policy stays authoritative for supported release lines, the OS Version Support Policy for minimum versions and the 90-day notice, the Deprecation Policy for removal criteria, and the Privacy Manifest for what is collected. These documents reference them rather than restating them.
• Forward references. SUPPORT.md and DATA_RESIDENCY.md link to DATA_DELETION.md, CONSENT_MANAGEMENT.md, RECORD_RETENTION.md, and VENDOR_RISK.md, which are being added in the companion data-protection pull request. The links resolve once both land. They are included deliberately so the set is navigable from any entry point, and can be dropped if you would rather each pull request stand alone.
• Enforcement status is stated in each document. Adoption monitoring, response-time measurement, and provider-region verification are human activities; the CI-enforced parts are named. This follows the pattern in COMMIT_SIGNING.md.
• Scope. Each issue adds exactly one new file inside Governance/. The four are grouped because they describe one lifecycle — what is supported, for how long, and how support ends — and cross-reference each other; each remains independently reviewable at one file per issue.
• No tests are added or changed. These are documentation-only files, and nothing outside Governance/ is touched.

Closes #1493
Closes #1494
Closes #1495
Closes #1496

[drips-wave]

@sadeeq6400 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Thank you for contributing to the project