docs: document the clean --raid modes

[ideaship]

Documents the RAID handling of osism baremetal clean, including the three named modes
added in:

• baremetal: give clean --raid three named modes python-osism#2633

Neither page mentioned any clean flag before this — not --raid, not
--metadata-only — and software-raid.md described the array as something only
osism baremetal deploy ever applies.

node-deployment.md

Extends the existing clean section with the three modes, the bare --raid shorthand,
how --metadata-only interacts with them, and the recreate refusal rules including
that --all skips and reports rather than aborting, then exits non-zero.

Also states that a mixed fleet needs no special handling. That is the common case — half
the nodes have a target_raid_config, half have no RAID interface at all — and since
the modes only ever apply to nodes with a RAID interface, one --all run does the right
thing for both halves. Worth saying explicitly, because there is no way to select a
subset of nodes even if one were needed.

The argument order caveat is documented because it is not guessable: --raid takes an
optional value, so a node name written directly after it is claimed as the value and
clean --raid node101 is rejected.

software-raid.md

New section on building or rebuilding the declared array without a deployment, which is
what --raid recreate is for, plus the reason delete and erase have to precede the
create step (Ironic's create step does not remove existing disks and fails on a
partitioned target) and the --metadata-only --raid recreate variant for hardware whose
disks cannot be erased in band.

Two things an operator can be caught by, now stated:

• A full clean removes the array by default. That was already true before the flag
  existed, and the page otherwise only ever mentions the array as something a deploy
  creates.
• Why recreate refuses a node with no target_raid_config rather than proceeding.
  Ironic accepts such a request and fails on the create step, which runs last, so the
  disks are already erased and the node lands in clean failed with maintenance mode
  set. Recovering means clearing the flag and cleaning again.

Checks

yarn build passes, which matters here because onBrokenLinks: 'throw' and the two
pages now cross-reference each other. markdown-table-formatter --check reports nothing
to reformat and codespell is clean.

Draft until the companion PR is reviewed; they should land together, since this
documents flags that do not exist on main yet.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Max errors	Warnings	Elapsed time
✅ ACTION	actionlint	5		0		0	0.05s
✅ JSON	jsonlint	4		0		0	0.11s
✅ JSON	prettier	4		0		0	0.32s
✅ JSON	v8r	4		0		0	8.98s
✅ MARKDOWN	markdownlint	169		0		0	2.74s
✅ MARKDOWN	markdown-table-formatter	169		0		0	0.43s
✅ REPOSITORY	betterleaks	yes		no		no	0.67s
✅ REPOSITORY	checkov	yes		no		no	19.73s
✅ REPOSITORY	git_diff	yes		no		no	0.06s
✅ REPOSITORY	secretlint	yes		no		no	3.64s
✅ REPOSITORY	trufflehog	yes		no		no	4.04s
✅ SPELL	codespell	179		0		0	0.74s
✅ SPELL	lychee	179		0		0	40.42s
✅ YAML	prettier	6		0		0	0.41s
✅ YAML	v8r	6		0		0	7.73s
✅ YAML	yamllint	6		0		0	0.54s

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@10.0.0 --custom-flavor-setup --custom-flavor-linters ACTION_ACTIONLINT,JSON_JSONLINT,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_BETTERLEAKS,REPOSITORY_SECRETLINT,REPOSITORY_TRUFFLEHOG,SPELL_LYCHEE,SPELL_CODESPELL,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository