docs(security): drop an invented backport rule and fix the nightly counts

The previous commit added a backport prioritisation policy to SECURITY.md — by
severity, by reachability in a default configuration, and by adopter count, with
a critical fix reaching every supported line. No such rule exists in any project
document. Reachability appears only as a triage question, and adopter count
appears nowhere. In an adopter-facing file that also lists seven supported
lines, that sentence read as a guarantee no maintainer has made. Replaced with
what is actually true: backporting is decided per fix and the rule is not
documented.

Nightly figures corrected. Counting only scheduled runs, the first run after
the fix still failed, the streak that followed was three days rather than four,
and six of the last twenty-four passed rather than seven. The earlier numbers
folded in a workflow_dispatch success from a day whose scheduled run failed.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>

GENERAL_TECHNICAL_REVIEW.md

@@ -87,7 +87,7 @@
 
 * **Enable/disable in a live cluster.** Cozystack is the distribution rather than an add-on toggled inside a foreign cluster, so "enablement" = installing the operator bundle on the management cluster. Individual bundles/components and each tenant application are enabled/removed independently (create/delete the corresponding resource); removing a tenant application affects only that tenant, with no downtime to unrelated workloads. `[maintainers: confirm whether any core component change requires control-plane restart]`
 * **How enablement changes default cluster behavior.** Installing Cozystack sets the CNI (Cilium/Kube-OVN), default StorageClass (LINSTOR), ingress, cert-manager, and the aggregated API as cluster defaults for subsequently created workloads. Cozystack expects to own the cluster, so a clean install does not disturb pre-existing unrelated workloads.
-* **Testing enablement/disablement.** CI installs Cozystack end-to-end in ephemeral environments and provisions/destroys sample tenants and applications to validate create→ready→delete flows. Workflows: [`pull-requests.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/pull-requests.yaml) (per-PR checks), [`e2e-tag.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/e2e-tag.yaml) (tag/release e2e), [`nightly.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/nightly.yaml) (scheduled full run) and [`ui-test.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/ui-test.yaml) (dashboard). Test conventions are documented in [`docs/agents/e2e-testing.md`](https://github.com/cozystack/cozystack/blob/main/docs/agents/e2e-testing.md). **Current health, so that a reviewer following these links is not surprised:** the gating checks are the per-PR ones — `pre-commit` and `E2E Tests` are the two required status checks on `main`, and a change cannot merge without them passing. The scheduled runs are another matter. `nightly.yaml` is **flapping rather than simply broken**, and has been for a month: after the fix in [cozystack#3332](https://github.com/cozystack/cozystack/pull/3332) it passed for four days, went red for five, passed for three ending 2026-08-01, and has failed every scheduled run since 2026-08-02. Seven of its last twenty-four scheduled runs passed. The current failure has **not been triaged to an issue** — several e2e failures from the same window are open and may share a cause, and the older nightly item in [cozystack#3278](https://github.com/cozystack/cozystack/issues/3278) describes the earlier never-completing failure rather than this one — so the honest statement is that the scheduled full-matrix run is unreliable and its current failure is not yet attributed. The tag-triggered `e2e-tag.yaml` also failed around the v1.6.1 release. Enablement and disablement coverage therefore rests on the per-PR e2e job today, and restoring the scheduled full-matrix run is outstanding work.
+* **Testing enablement/disablement.** CI installs Cozystack end-to-end in ephemeral environments and provisions/destroys sample tenants and applications to validate create→ready→delete flows. Workflows: [`pull-requests.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/pull-requests.yaml) (per-PR checks), [`e2e-tag.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/e2e-tag.yaml) (tag/release e2e), [`nightly.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/nightly.yaml) (scheduled full run) and [`ui-test.yaml`](https://github.com/cozystack/cozystack/blob/main/.github/workflows/ui-test.yaml) (dashboard). Test conventions are documented in [`docs/agents/e2e-testing.md`](https://github.com/cozystack/cozystack/blob/main/docs/agents/e2e-testing.md). **Current health, so that a reviewer following these links is not surprised:** the gating checks are the per-PR ones — `pre-commit` and `E2E Tests` are the two required status checks on `main`, and a change cannot merge without them passing. The scheduled runs are another matter. `nightly.yaml` is **flapping rather than simply broken**, and has been for a month: the first scheduled run after the fix in [cozystack#3332](https://github.com/cozystack/cozystack/pull/3332) still failed, then it passed for three days, went red for five, passed for three more ending 2026-08-01, and has failed every scheduled run since 2026-08-02. Six of its last twenty-four scheduled runs passed. The current failure has **not been triaged to an issue** — several e2e failures from the same window are open and may share a cause, and the older nightly item in [cozystack#3278](https://github.com/cozystack/cozystack/issues/3278) describes the earlier never-completing failure rather than this one — so the honest statement is that the scheduled full-matrix run is unreliable and its current failure is not yet attributed. The tag-triggered `e2e-tag.yaml` also failed around the v1.6.1 release. Enablement and disablement coverage therefore rests on the per-PR e2e job today, and restoring the scheduled full-matrix run is outstanding work.
 * **Resource cleanup incl. CRDs.** Deleting an application resource triggers Flux/Helm to remove its HelmRelease and owned objects; finalizers ensure dependent resources (PVCs, VM disks, LB IPs) are released. `[maintainers: confirm CRD-cleanup behavior on full uninstall and any manual steps]`
 
 ### Rollout, Upgrade and Rollback Planning

SECURITY.md

@@ -26,7 +26,7 @@ The test is *recent patch activity on the line*, not the existence of a `release
 
 This table describes the support the project provides in practice. It is not a contractual guarantee of a fixed backport window: the six- and eighteen-month marks are how we describe current behaviour so that adopters can determine their own status, not a commitment to patch any line for that long.
 
-Applied today, the activity test classifies every `1.x` line from `1.0` to `1.6` as supported, because each has had a patch release within six months. That is a wide set, and it is deliberate rather than accidental — the project cuts minors frequently and adopters do not all move at that pace. It does not mean every line receives every fix. Backport effort is prioritised by severity, by whether the affected component is reachable in a default configuration, and by how many known adopters are on the line, so a critical fix reaches every supported line while a moderate one may land only on the most recent. The lower rows of the table are therefore forward-looking today: no `1.x` line has yet gone six months without a patch.
+Applied today, the activity test classifies every `1.x` line from `1.0` to `1.6` as supported, because each has had a patch release within six months. That is a wide set, and it is deliberate rather than accidental — the project cuts minors frequently and adopters do not all move at that pace. It does not mean every line receives every fix: whether a given fix is backported to a given supported line is a maintainer decision taken per fix, and the project does not currently document a rule for it. The lower rows of the table are therefore forward-looking today: no `1.x` line has yet gone six months without a patch.
 
 Reporting a vulnerability against a line with limited support or at end of life is still welcome. We will confirm whether the issue also affects a maintained line and fix it there; whether the fix is additionally backported to an older line is a maintainer decision based on severity and upgrade impact.