docs(governance): add key, certificate, vulnerability SLA, and patch management policies

[ayshadogo]

Summary

Adds four asset-lifecycle policies under Governance/policies/, closing the governance gaps tracked in #1489, #1490, #1491, and #1492.

Policy	Closes	Covers
KEY_MANAGEMENT.md	#1489	Key inventory, generation, storage and access, rotation, revocation, destruction, verification
CERTIFICATE_MANAGEMENT.md	#1490	Issuance, renewal, ownership, expiry monitoring, revocation, certificate inventory
VULN_SLA.md	#1491	Remediation targets per severity, measurement, escalation when a target is missed
PATCH_MANAGEMENT.md	#1492	Patch cadence by class, prioritisation, emergency-patch path

What these documents add

Key lifecycle. A key inventory table giving every key group an owning role — iOS distribution certificate, provisioning profile, App Store Connect .p8, Android upload keystore, Play service-account key, commit-signing keys, on-device feature-cache data key, CI tokens — because a key nobody can enumerate is a key nobody can rotate. Storage rules require that a data key never sits beside the ciphertext it protects, which is how src/utils/encryptedStorage.ts already works. Revocation is defined as removing trust at the source, since overwriting a stored value is not revocation.

Certificate lifecycle. Issuance is restricted to controlled issuers with the private key generated where it will be stored; renewal lead times are 30 days generally and 60 days for Apple-issued material, because profile regeneration is not always immediate; the superseded certificate is retained until a production build is accepted, giving a rollback position. An inventory records the issuer, purpose, owner, and expiry source of truth for each certificate.

Remediation targets. Targets are measured from awareness to release in users' hands, not to merge — a fix merged to main but not released does not stop the clock. Mitigations only count if they remove the exposure, so disabling a feature behind a flag qualifies while a monitoring rule does not. Each target has a matching "available to users" window that includes app-store review lead time, and a store delay is recorded as a store delay rather than counted against the team. The acknowledgement targets in the existing severity rubric continue to apply unchanged and are measured separately.

Escalation on a miss. A missed target is declared within one business day with its cause stated, escalated immediately for Critical and High, and paired with a follow-up task that removes the structural cause — the missing advisory alert, the untested path, the single maintainer who alone understands the area. Missing a target is explicitly not a fault if it is declared and explained; hiding it or silently extending the deadline is.

Patch cadence and prioritisation. A window per patch class, from 24 hours for an actively-exploited signing-chain compromise to a milestone for a framework upgrade. Prioritisation is an ordered rule set where reachability is assessed rather than assumed, so an advisory for an unused code path is not automatically deprioritised — severity is only lowered with a written argument. Routine batches are size-bounded so a regression stays attributable.

Emergency path. Shortens the process without removing controls: two maintainer approvals minimum, a scoped diff, a dedicated branch, a preview build confirmed before promotion, the full suite recovered within 24 hours, and a post-incident review for anything the emergency deferred.

Notes for reviewers

• Boundaries with existing governance are deliberate. APP_SIGNING_KEYS.md keeps custody and rotation of signing material, SECRET_ROTATION.md keeps credential cadence, SECURITY_SEVERITY_RUBRIC.md keeps the severity definitions and acknowledgement SLAs, and REVIEW_SLA.md keeps review turnaround. These documents link to those rather than restating them, so there is one authoritative source per rule.
• Claims are checked against the repository. The inventory names the real key types from APP_SIGNING_KEYS.md, the expo-crypto key generation in src/utils/encryptedStorage.ts, and the fact that audit.yml runs on push and weekly and fails on high and critical advisories.
• Enforcement status is stated in each document. Expiry-age checking, advisory matching, and batch-size limits are human processes today; the automated controls that do exist are named. This follows the pattern in COMMIT_SIGNING.md and avoids describing controls that are not implemented.
• Scope. Each issue adds exactly one new file inside Governance/. The four are grouped into one pull request because they define one lifecycle across related assets 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 #1489
Closes #1490
Closes #1491
Closes #1492

[drips-wave]

@ayshadogo 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