fix: --no-parallel can override a profile's parallel_processing=True

Round 11 confirmed a real precedence bug in both \`replay\` and
\`generate\`:

  par = parallel or params.get(\"parallel_processing\", False)

When the user explicitly passed --no-parallel (parallel=False) but
the active profile sets parallel_processing=True, the OR evaluated
to True and the user's explicit choice was silently discarded.
Users had no way to disable parallel execution for a profile that
enabled it.

Fix: make --parallel tristate.
- The Typer option is now \`Optional[bool] = typer.Option(None,
  \"--parallel/--no-parallel\", ...)\` so explicit absence (None)
  distinguishes from explicit False.
- The precedence rule becomes the standard pattern used for all
  other numeric flags: \`parallel if parallel is not None else
  profile.get(\"parallel_processing\", False)\`.

Behaviour after fix:
- no flag:               use profile (or False if no profile)
- --parallel:            True, overrides profile
- --no-parallel:         False, overrides profile

Tests:
- tests/test_cli.py::TestEdgeCases::test_no_parallel_overrides_profile
  uses an unittest.mock patch to capture the resolved GenerateConfig
  and asserts cfg.parallel is False after --no-parallel + profile
  generate_standard (which sets parallel_processing=True).

Also adds bin/audit_profile_adapter.py with:
- DD: profile/CLI precedence across batch_size, parallel (replay +
  generate), and timing_model.
- EE: validate_output happy/sad paths -- empty dir, missing dir,
  matching dir, unknown adapter name.

Round 11: 9/9 scenarios pass post-fix. Suite: 804 passed.

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

Author: druvus