updated release management guide with new instructions for docs build

[zenmonkeykstop]

Status

Ready for review

Description of Changes

Resolves #5081.

Updates release management docs with instructions on updating public documentation.

Testing

• Docs-only PR, review for clarity and correctness.

Deployment

Any special considerations for deployment? Consider both:

1. Upgrading existing production instances.
2. New installs.

Checklist

If you made changes to documentation:

• Doc linting (make docs-lint) passed locally

[eloquence]

The previous version said:

Building from the branch instead of a given tag enables us to more easily add documentation changes after release.

With this new process, I think we should make the expectations for post-release/post-tag docs updates even more explicit, to avoid confusion about what's permissible, and to avoid missing required steps.

What's the expected process going forward?

1. Will we still permit post-tag backports of docs changes into the release branch, without creating a new tag?
2. Will such docs changes then need to be individually ported into master, or is the expectation to do a single merge to master once towards the very end of the process?

[eloquence]

Per the discussion at our retro, we also want to clarify what merge strategy we want to use here (ideally one that is low-effort, since master is only used for docs builds).

[kushaldas]

This is good, and simple step compared to the previous steps.