docs(skills): recommend a week-long test period before the release vote

.claude/skills/creating-release-vote-mail/SKILL.md

@@ -12,10 +12,12 @@ boilerplate, around a plain-text rendering of the release's Version Notes page.
 
 **Core principle:** the mail is a *rendering* of the page, not a second account of the release.
 
-**This is the step after `creating-version-notes`.** That skill produces the page, the GitHub
-release and the `[TEST]` announcement; this one consumes all three. If they do not exist yet,
-you are in the wrong skill. `releasing-struts` holds the surrounding phases and what happens
-once the vote passes.
+**This is the step after `creating-version-notes`, and after the test period.** That skill
+produces the page, the GitHub release and the `[TEST]` announcement; this one consumes all three.
+If they do not exist yet, you are in the wrong skill. Between them sits the test period, about a
+week by recommendation, whose length is the release manager's call: run this skill when they ask
+for the vote, never because the `[TEST]` mail has gone out. `releasing-struts` holds the
+surrounding phases and what happens once the vote passes.
 
 [`vote-mail-template.md`](vote-mail-template.md) is the source of truth for the artifact.
 

.claude/skills/creating-version-notes/SKILL.md

@@ -297,7 +297,7 @@ for the `[VOTE]`.
 
 Keep the security posture of the pages: the mail links the release notes, it does not summarise what is in them, so no severity, CVE or S2-XXX reaches it either.
 
-**The vote is the next step, and it is a different mail.** Once the test build is announced, `creating-release-vote-mail` composes the `[VOTE] Apache Struts X.Y.Z` call — to `dev@` alone, rendered from the page this skill produced. Do not draft it from here: its recipients, subject and body all differ from the announcement above.
+**The vote is a later step, and it is a different mail.** Once the test build is announced, the release waits for testers — about a week by recommendation, the release manager decides. When they call the vote, `creating-release-vote-mail` composes the `[VOTE] Apache Struts X.Y.Z` call — to `dev@` alone, rendered from the page this skill produced. Do not draft it from here: its recipients, subject and body all differ from the announcement above, and the test mail going out is not the trigger.
 
 ## Re-read the page immediately before you write to it
 

.claude/skills/releasing-struts/SKILL.md

@@ -124,6 +124,10 @@ answer is the last release, not the last wiki revision.
 
 - **A closed Nexus staging repo, not just a successful `release:perform`.** Until it is closed
   the URL in the Version Notes resolves to nothing and every tester is blocked.
+- **A test period between the `[TEST]` mail and the `[VOTE]`, about a week by recommendation.**
+  Its length is the release manager's call, not a gate you enforce: when phase 3 is done, state
+  the recommended earliest vote date and stop. Do not draft or offer the vote mail on your own
+  initiative; the release manager opens phase 4.
 - **72 hours, and three binding `+1`.** PMC votes are the binding ones; `private@` is on the
   vote mail so binding voters see it.
 - **24 hours after the `dist` move, before announcing.** ASF mirroring guidance. Announcing into