feat(extract): add CLI flags for extraction modes and enrichment orchestrator - #227

In
`@packages/riviere-cli/src/features/extract/entrypoint/extract.enrichment.spec.ts`:
- Around line 145-294: Add a test to the existing "enrich flag" suite that
verifies the CLI rejects providing both --components-only and --enrich together:
create configWithLiteralExtract and a draftPath JSON file, call
createProgram().parseAsync with args including '--components-only' and
'--enrich' plus the draftPath, assert the promise rejects with an exitCode
indicating validation error (e.g. 2), then use
parseErrorOutput(ctx.consoleOutput) to assert the error message contains
"mutually exclusive"; place this test near the other enrich flag tests so it
uses the same TestContext and helpers (createProgram, parseErrorOutput,
configWithLiteralExtract, draftPath).
- Around line 22-27: Replace the local DraftComponent interface with an import
from `@living-architecture/riviere-extract-ts`: remove the locally declared
"interface DraftComponent { type: string; name: string; domain: string;
location: ComponentLocation }" and add an import for DraftComponent (and
ComponentLocation if not already imported) from the package so tests use the
canonical type; mirror the pattern used in the sibling test
extract.dry-run.spec.ts to locate the correct import name and update any
references to DraftComponent in the file accordingly.
- Around line 162-166: Update the test's expected location so the enrichment
finds the class declaration: in the location object inside
extract.enrichment.spec.ts (the entry that uses join(srcDir,
'order-service.ts')), change the line property from 2 to 3 so it points at the
actual class declaration line (`export class PlaceOrder {`) rather than the
JSDoc line.

In `@packages/riviere-cli/src/features/extract/entrypoint/extract.ts`:
- Around line 211-217: The catch in parseJsonFile swallows the JSON parse error;
update parseJsonFile to capture the thrown error (e.g., catch (err)) and pass
the error message/details into exitWithRuntimeError so the runtime error
includes the original JSON parse error and the file path, making debugging
easier; reference the parseJsonFile function and the exitWithRuntimeError call
when implementing this change.

In @.claude/agents/code-review.md:
- Around line 8-10: There is a contradiction between the hard requirement line
"CRITICAL: Your very first output line MUST be exactly `PASS` or `FAIL`." and
the learning statement that says not to enforce rigid, machine-parsed output
formats; resolve by choosing one approach and updating the doc: either
remove/soften the "CRITICAL: Your very first output line MUST be exactly `PASS`
or `FAIL`." clause (or make it optional/annotated with why an orchestrator needs
it), or update the learning statement to acknowledge the orchestrator
requirement; ensure you change the exact quoted rule text and the learning
sentence so both are consistent and include brief rationale for the chosen
design.
- Around line 58-78: The "Full Audit Trail" requirement forces every PR to
include verdict rows for all 54 rules (SD-001..SD-021, AP-001..AP-006,
SP-001..SP-002, TS-001..TS-011, CS-001..CS-008, CR-001..CR-006), creating
excessive noise; change this to a scoped-audit policy that evaluates only
applicable rule sets based on changed files: detect file types/paths in the PR
and map them to rule groups (e.g., docs → CR-only, tests → TS + relevant SD/AP,
production code → full audit), generate verdict rows only for rules in the
selected groups, and mark other groups as intentionally out-of-scope (no
per-rule N/A rows) while keeping at least a summary line stating which rule sets
were evaluated; update the "Full Audit Trail" section and any code that renders
the audit table to implement this mapping and selection logic.

In `@docs/conventions/software-design.md`:
- Line 7: The document contains a duplicate "SD-001" heading which creates
conflicting anchors/TOC links; locate the second "SD-001" heading and either
rename it to a distinct title (suggestion: "SD-001: Fail-Fast Error Handling
(Details)") or convert it into a subheading beneath the primary SD-001 section,
then update any internal links/TOC references that point to the old duplicate
anchor so they reference the new unique heading.
- Line 365: The heading "SD-021: YAGNI - You Aren't Gonna Need It" uses informal
wording; update the title and any occurrences of "gonna" in the SD-021 section
to the formal phrase "going to" (e.g., change "You Aren't Gonna Need It" to "You
Aren't Going to Need It" or "You Are Not Going to Need It") to match the
conventions document tone and ensure consistency across the SD-021 section.

In `@docs/conventions/software-design.md`:
- Line 299: Locate the run-on sentence in the documentation section flagged by
the reviewer (the sentence that joins two independent clauses without proper
punctuation) and fix it by either adding a coordinating conjunction with a comma
(e.g., ", and" or ", but") between the clauses or by splitting it into two
separate sentences; ensure the second clause is capitalized and punctuation/verb
agreement remains correct after the change.

In `@tools/dev-workflow/platform/domain/workflow-execution/run-workflow.ts`:
- Around line 14-23: The exported function runWorkflow references non-exported
types WorkflowOptions, ContextBuilder, and ResultFormatter which causes
declaration emit errors; fix this by exporting those type declarations (add the
export keyword to the WorkflowOptions interface and to the ContextBuilder and
ResultFormatter type/interface declarations or re-export them from this module)
so the public signature only uses exported symbols, and update any
imports/exports if those types live in another file.