fix(decisioning): inline env var literal + drop INVALID_REQUEST backticks (#423 fix-pack)

The docstring-vs-code consistency test (#424, just merged) caught two
issues in this PR:

1. The strict-mode env-var read used os.environ.get(_STRICT_VALIDATE_ENV)
   indirection, which the consistency test's regex doesn't follow.
   Inline the literal 'ADCP_DECISIONING_STRICT_VALIDATE_PLATFORM' string
   so the test sees the read.

2. The docstring wrapped 'INVALID_REQUEST' in backticks on lines near
   env-var context keywords, tripping the test's SCREAMING_CASE heuristic
   (it treats backtick-wrapped uppercase tokens as candidate env vars).
   INVALID_REQUEST is a spec error code, not an env var — drop the
   backticks so it's plain prose.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: bokelley

src/adcp/decisioning/dispatch.py

@@ -383,7 +383,10 @@
 
 def _strict_validate_platform() -> bool:
     """True when the strict-validate env var is set to ``"1"``."""
-    return os.environ.get(_STRICT_VALIDATE_ENV, "") == "1"
+    # Inline the literal name so docstring-vs-code consistency tests can
+    # match it via plain regex (the test scans for ``os.environ.get("FOO")``
+    # patterns and doesn't follow the indirection through ``_STRICT_VALIDATE_ENV``).
+    return os.environ.get("ADCP_DECISIONING_STRICT_VALIDATE_PLATFORM", "") == "1"
 
 
 # ---------------------------------------------------------------------------
@@ -502,14 +505,14 @@ def validate_platform(platform: DecisioningPlatform) -> None:
     3. Each claimed specialism's required methods are implemented
        on the platform subclass. Unknown specialisms emit
        ``UserWarning`` (forward-compat with v6.x+ specs); known
-       specialisms missing methods raise ``AdcpError("INVALID_REQUEST")``.
+       specialisms missing methods raise an INVALID_REQUEST error.
     4. Each claimed specialism's *recommended* methods (the v6.0 rc.1
        staging set in :data:`RECOMMENDED_METHODS_PER_SPECIALISM` —
        sales-* surface broadening per DX-423) are implemented on the
        platform subclass. Misses emit one ``UserWarning`` per
        method (deduped across overlapping specialisms). Setting
        ``ADCP_DECISIONING_STRICT_VALIDATE_PLATFORM=1`` flips the soft
-       warning into a hard ``AdcpError("INVALID_REQUEST")``.
+       warning into a hard INVALID_REQUEST error.
     5. **Governance opt-in fail-fast (D15 round-4):** if any claimed
        specialism is in :data:`GOVERNANCE_SPECIALISMS` AND
        ``capabilities.governance_aware`` is False AND the platform