Docs: clarify multisite staging template reset behavior (408098)

[cursor]

JIRA: https://vendasta.jira.com/browse/WSP-3233

Change classification

• Feature behavior change (user-facing behavior in WordPress Hosting Pro staging reset flow)
• UI/UX change (reset option visibility for multisite in staging reset actions)

Summary of documentation updates

• Updated existing documentation page:
  • docusaurus/docs/vendasta-services/websites/vendasta-services-website-support.md
• Added a new FAQ entry under existing Website Support FAQs:
  • Can I reset staging from a template for premium multisite websites?
• Documented current behavior only:
  • Reset from a template is available for premium multisite websites
  • Staging is configured as multisite after template apply
  • Option is available for single-site and multisite websites

Existing docs updated vs new docs created

• Updated existing docs (no new page created)

Placement reasoning

• The repository does not contain a dedicated WordPress Hosting Pro staging workflow page.
• The most relevant existing location mentioning WordPress Hosting Pro dashboard operations is Website Support.
• Adding a focused FAQ entry keeps information discoverable without creating a disconnected top-level doc.

Acceptance criteria coverage mapping

• Multisite reset from template works: Covered by FAQ statement that multisite reset from template is supported and staging is configured for multisite.
• UI shows the option: Covered by FAQ statement that Reset from a template is available for premium multisite websites.
• Single-site not affected: Covered by FAQ statement that option is available for single-site and multisite websites.
• Create staging not affected: Not explicitly documented (no behavior change described in current docs corpus; no new user instruction details beyond regression expectation).
• Reset to live not affected: Not explicitly documented (regression expectation, no new end-user behavior to document).
• Distributed template filtering preserved: Not documented; implementation detail/conditional logic not present in existing user-facing docs.
• Tested on demo: Internal validation detail, not user-facing documentation content.

Visual inputs usage

• No Jira attachments or Figma links were provided in the payload for this automation run.
• Documentation was based on Jira text and acceptance criteria.

Skills used

• sprint-review skill (/workspace/.cursor/skills/sprint-review/SKILL.md) for conservative, release-only, evergreen documentation update workflow.

Assumptions and limitations

• Linked code PR author identities were not directly accessible from available payload/GitHub search results in this environment.
• Jira metadata indicates linked PRs exist (merged count), but resolvable author handles were not available to safely tag.

Mentions

@ahnikakuse
@haleyserrano
@maryam6samadi