Enforce rules across compound POSIX commands

[ronheichman]

Why

Rules that use shell_commands can detect a matching command inside compound
POSIX input, but enforcement currently requires the entire input to be one
simple command or pipeline. Inputs such as echo ready; cat .env are therefore
detected without being denied even when the matching rule is enforce-enabled.

What changed

• Derive independent static command candidates from the existing POSIX syntax
  tree, keeping direct pipeline members together.
• Evaluate the same checked CEL predicate against those candidates while
  retaining the complete command list for detection.
• Carry candidate-safe verdicts through sequence rules and invalidate persisted
  sequence projections whose enforcement masks used the previous semantics.
• Track inherited redirects and literal interpreter input so eligible heredoc
  commands can participate, while keeping invalid, unsupported, and
  unvalidated named interpreter options detection-only.
• Document the candidate model and cover compound forms, parser errors, dynamic
  siblings, interpreter options, descriptors, checked expressions, and sequence
  enforcement.

Safety and compatibility

This expands blocking only for eligible POSIX candidates. Dynamic executables,
runtime-expanded arguments or redirects, unsafe direct pipelines, inline
interpreters, eval, malformed commands, unvalidated named interpreter
options, and compound PowerShell or CMD input remain detection-only or produce
their existing analysis diagnostic. Statically resolved shell-function calls
also remain detection-only; eligible commands in an invoked function body are
considered separately.

There are no wire-format or rule-schema changes. Both sides of && and ||
are intentionally treated as requested command intent, even when one branch may
not execute.