docs(agents): the documented HR-Ready timeout standard is crossed by five suites #3741

docs/agents/e2e-testing.md:159 tells an agent what a normal HelmRelease-Ready timeout looks like, and the numbers it gives no longer match the suites:

Standard HR-Ready assert timeout is 5–6m; longer waits (harbor 10m, NFS 10m, VM image pulls, platform-wide install 15m) are justified in-line.

The tree currently holds five waits longer than the documented ceiling, none of which the sentence accounts for:

hack/e2e-chainsaw/kubernetes-latest/chainsaw-test.yaml:48    timeout: 50m
hack/e2e-chainsaw/kubernetes-previous/chainsaw-test.yaml:42  timeout: 50m
hack/e2e-chainsaw/postgres/chainsaw-test.yaml:323            timeout: 40m
hack/e2e-chainsaw/mariadb/chainsaw-test.yaml:288             timeout: 30m
hack/e2e-chainsaw/etcd/chainsaw-test.yaml:309                timeout: 20m

Why it matters more than a stale number

The sentence is a review yardstick. An agent writing a new suite reads it as "anything past 6m needs an argument", and a reviewer reads it as grounds to push back. Both are working from a ceiling the tree crossed five times without anyone updating the line, so the guidance produces friction where there is none and silence where a real outlier would deserve a question.

The list of exceptions is the part that decayed: it names harbor, NFS, VM image pulls and platform install, and each of those is still plausible, which is exactly why the sentence still reads as maintained.

What would fix it

Not another number. The useful form states where a timeout should come from, and there is a good example already in the tree: the OIDC fixtures take theirs from release.cozystack.io/helm-install-timeout on the ResourceDefinition, so the assert cannot outlive or undercut the install it waits on. A rule like "derive it from the install ceiling that governs the release, and say in-line which ceiling that is" survives every future suite; a number does not.

Whoever picks this up should also decide whether the exception list belongs in prose at all, given that it went stale silently and nothing enforces it.

Scope

Pre-existing. Found while reviewing an unrelated change that adds another wait longer than the documented standard, which is what prompted the check.