docs(release): pause v1.x Cloud Vetting iteration; file publisher support ticket

v1.0.8's ">=8.1.0,<10.0.0" was rejected with the CONTENT-class wording
("no supported version of Splunk Enterprise: >=8.1.0,<10.0.0"). This
confirms the comma-no-space syntax PARSES correctly (no "Illegal
version specification" syntax error) but Cloud Classic's supported-
version set is somewhere we cannot reach through guesses.

9 empirical data points across F13-F19 + v1.0.0 pre-release + v1.0.8
do not triangulate to any defensible next single-version or range:

  Format                              Error class   Result
  ----------------------------------  -----------   ----------
  "9.3"                               (accepted)    v1.0.0/v1.0.1, retired
  "10.0"                              content       REJECTED v1.0.3
  "9.4"                               content       REJECTED v1.0.4
  ">=9.0.0"                           content       REJECTED v1.0.5
  ["9.4", "10.0"]                     type          REJECTED v1.0.2
  ">=8.1.0 <10.0.0"   (space-only)    syntax        REJECTED v1.0.6
  ">=8.1.0, <10.0.0"  (comma+space)   syntax        REJECTED v1.0.7
  ">=8.1.0,<10.0.0"   (comma+nospace) content       REJECTED v1.0.8

The Splunkbase AI explainer's v1.0.8 recommendation was ">=9.0.0" —
literally the v1.0.5 value that already content-rejected. The AI is
now recycling known-failed values.

Per the documented escalation rule (every prior reversal row's "if
v1.0.N+1 also fails" clause), the iteration cost (8 releases over
7 days, all publicly visible on Splunkbase listing 8800) now exceeds
the support-ticket cost. This commit formalizes the decision.

What changed:
- docs/SPLUNKBASE_SUPPORT_TICKET.md (new): full ticket draft ready to
  send. Contains the cumulative empirical evidence + the specific
  questions for Splunkbase Publisher Support. Includes a "Ticket
  tracking" section to fill in after sending. Also documents what
  we'll do with each possible response class (specific version /
  specific range / on-prem-only fallback).
- docs/DECISION_LOG.md 2026-06-07 row: documents the escalation
  decision. Captures the "iteration-cost-now-exceeds-direct-query-cost"
  threshold rule for future maintainers facing similar SLIM/AppInspect
  discovery problems.
- CLAUDE.md "Splunk Version Pinning Audit" log: new row with the
  escalation + the pattern observation that prior 6 reversal rows
  kept deferring this same decision.

What did NOT change:
- app.manifest stays at ">=8.1.0,<10.0.0" — comma-no-space syntax is
  the established correct parse form even though the version set
  doesn't match. No new release.
- No new tag, no new GitHub release. Splunkbase listing 8800 stays
  at v1.0.8 awaiting the ticket response.
- All app code, dashboards, RBAC, scripted inputs unchanged across
  v1.0.0 -> v1.0.8 + this escalation.

Note on the v1.0.8 SLIM report's supplementary findings:
The report also showed 10 "Undefined setting" lines about
python.version / python.required in inputs.conf / restmap.conf /
commands.conf. These are NOT new — they're the F2-F11 spec drift
between SLIM and AppInspect already documented in
docs/APPINSPECT_FINDINGS.md sections 5.2 and 5.7. Phase 1.7's
accepted disposition was "live with the SLIM noise" because removing
the settings breaks AppInspect's check_python_version_correctness_
for_splunk_enterprise. They appear in the upload report because
Splunkbase's hosted SLIM step doesn't honor our
.appinspect_api.expect.yaml suppressions. No action needed.

What I'll do with the ticket response (per
docs/SPLUNKBASE_SUPPORT_TICKET.md "What I will do with the response"):

- If Splunkbase gives a specific version string: cut v1.0.9 with that
  value verbatim; add CANONICAL row to cumulative format history.
- If Splunkbase confirms on-prem-only path: update INSTALLATION.md /
  README.md to remove Cloud Vetting language; codebase stays as-is.

Verification:
- bash scripts/pre-commit-doc-drift.sh -> OK (50 docs vs build 678)
- No code changed; no validate.sh / preflight-tag run needed.
- v1.0.8 release artifacts on GitHub stay as-is.

Author: RelativisticJet