Document cleaning up fixtures after a successful beaker run

[miharp]

Summary

• Document cleaning up fixtures after a successful rake beaker run: fixtures:prep has a matching fixtures:clean task, but nothing invokes it automatically, so show enhancing the beaker task with a post-action
• Note that cleanup is skipped when the acceptance tests fail (verified locally — RSpec::Core::RakeTask signals failure via exit rather than a raised exception, which skips the enhance block), leaving fixtures in place for debugging

Follow-up to #433/#435, from a live question in Vox Pupuli Slack (Hugo Haakseth, after applying the fixtures:prep fix from #435).

Test plan

• bundle exec rake rubocop
• markdownlint-cli2 on the changed file
• bundle exec jekyll build
• Reproduced the documented Rake snippet standalone (rspec-core + rake, no full module) to confirm: fixtures:prep runs first, fixtures:clean runs after a passing run, and is skipped after a failing run

[h-haaks]

@miharp to use fixtures:prep and fixtures:clean with https://github.com/voxpupuli/gha-puppet/blob/v4/.github/workflows/beaker.yml the Gemfile has to be modified to load the openvox gem for system_tests group as well.

I created voxpupuli/modulesync_config#1048

with this modules under modulesync could just use this in .sync.yml

Gemfile:
  acceptance_uses_fixtures: true
Rakefile:
  acceptance_uses_fixtures: true

[miharp]

This PR only covers fixtures:clean. I have a follow-up for the same page that documents the Gemfile side: forge_modules: fixtures shell out to puppet module install, so the openvox gem has to be in the system_tests group too. Holding it until this merges so the two don't conflict on the same lines. Once modulesync_config#1048 lands I'll have the follow-up point modulesync-managed modules at acceptance_uses_fixtures: true instead of manual Gemfile edits.