chore: clear standards-check debt (shellcheck, zizmor pins, markdownlint scope)

[twistedmelonman]

Clears the lint debt that the new (non-required) standards-check workflow
reports on this repo. Three linters failed at baseline; two are now green and
the third is down to one finding that needs a decision from you rather than a
code change.

Results

Linter	Before	After
shellcheck	25 findings, 5 files	clean
markdownlint	408 findings, 111 files	clean
zizmor	5 findings	1 finding (adhoc-packages, deferred)
yamllint / actionlint / node-floor	clean	clean

run-standards.sh goes from 3 linter(s) failed to 1 linter(s) failed.

shellcheck — 25 fixed, 0 deferred

All 25 were under plugins/. Fixed in place, no # shellcheck disable. Most
are SC2312 on command substitutions whose exit status was already being
discarded, so || true documents the existing behavior rather than changing
it. Two edits are not purely cosmetic:

• protect-mcp/test/{run-tests,verify-fixtures}.sh gain cd ... || exit 1.
  Both use set -uo pipefail with no -e, so this adds a failure path that
  did not previously exist. The cd target is the script's own directory, so
  the new exit is unreachable in practice.

validate-chart.sh is worth a note as a non-change: it runs set -e, which
looks like the || true on its three Chart.yaml extractions might suppress
an abort. It does not. The script sets -e only, never pipefail, so
grep ... | awk ... already exited with awk's status, which is 0 even when
grep matches nothing. The missing-field case reached the script's own
error "Chart name not found" branch before this change and still does.

Both protect-mcp suites still pass after these edits (run-tests.sh 8/8,
verify-fixtures.sh 12/12), and bash -n is clean on all five scripts.

markdownlint — 111 files ignored, 0 fixed (0 exist outside plugins/)

All 408 findings are under plugins/. Zero Markdown files outside
plugins/ had a finding, so there was nothing to fix there.

This adds .markdownlint-cli2.jsonc with "ignores": ["plugins/**", "node_modules/**"], matching the scope this repo's own markdownlint CI job
already applies — it lints *.md and docs/*.md only, and its comment states
that per-plugin docs are owned by their plugin authors. The new file exists so
that tools which discover Markdown themselves (the fleet standards-check,
pre-commit hooks) apply that same scope.

Two notes on how it is wired:

• It uses "extends": ".markdownlint.json" rather than duplicating the rule
  list, so the two configs cannot drift.
• .markdownlint.json is unchanged, because this repo's own
  markdownlint-cli2-action reads it directly.

Verified the extends chain actually loads (a file with no trailing newline
is still correctly reported as MD047, rather than silently linting with an
empty ruleset), and that the repo's own CI globs still exit 0.

zizmor — 3 pins + 1 persist-credentials, 1 deferred

eval-report.yml was the only workflow left unpinned; every other workflow
here already uses SHA pins. Pinned to the latest patch of the major each was
already on:

Action	Pin	Tag
actions/checkout	34e114876b0b11c390a56381ad16ebd13914f8d5	v4.3.1
astral-sh/setup-uv	d4b2f3b6ecc6e67c4457f6d3e41ec42d3d0fcb86	v5.4.2
actions/upload-artifact	ea165f8d65b6e75b540449e92b4886f43607fa02	v4.6.2

Its actions/checkout also gains persist-credentials: false (artipacked);
the workflow runs no git push/git commit, so nothing depends on the
persisted token. The canonical fleet zizmor.yml is copied in verbatim, which
is what lets first-party smartwatermelon/github-workflows/... refs keep their
floating tags while third-party actions stay hash-pinned.

Deferred: one help[adhoc-packages] finding on validate.yml:248
(npm install -g @google/gemini-cli@latest). The canonical config documents
this pattern as accepted only for an exactly-pinned CLI, which @latest is
not, so silencing it locally would assert a policy that has not been agreed.
Pinning does not clear it either — verified against zizmor 1.30.0, the finding
persists at @0.1.0. Filed as #20 with three options. standards-check
will stay red on this one low-severity finding until that is decided.

Two things found but not changed (out of scope)

• .github/dependabot.yml has no github-actions ecosystem entry (only two
  uv entries), so the SHA pins added here will not be moved automatically.
• The astral-sh/setup-uv reference used elsewhere in this repo
  (e58605a9b6da7c637471fab8847a5e5a6b8df081) is the SHA of the annotated
  tag object v5, not of a commit. It is immutable and zizmor accepts it,
  so this is not a security gap — but it is inconsistent with the commit SHAs
  used for every other pinned action, and Dependabot expects commit SHAs. The
  new pin in eval-report.yml uses the dereferenced commit.

https://claude.ai/code/session_019HDRKLQNv82SEBd4zGpcXf