feat: decide whether skipped-file counts should affect archguard's exit code in --ci mode

[Tgenz1213]

Description

Found during review of #124 (PgStore.Search error handling). Engine.SkippedFiles (incremented for fetchContext, CreateEmbedding, and now Search failures — see internal/analysis/engine.go's skipFile closure) never affects archguard's exit code, in any mode, including --ci. Only violations > 0 (via analysis.DriftDetectedError, checked in internal/cli/cli.go) produces a non-zero exit.

This means a total infrastructure failure — e.g. Postgres unreachable for an entire check run, so every file's Search call fails — is now visible in printed output and counted in SkippedFiles, but the run still exits 0. In a CI pipeline that gates on exit code, drift checking can silently stop working entirely with a green build.

This isn't new to #124's fix — fetchContext/CreateEmbedding failures have always had this property. #124 just made Search consistent with that pre-existing behavior rather than fixing the underlying gap, since fixing it is a broader policy decision than a single-function fix.

Expected behavior

Decide and document: should a nonzero SkippedFiles (or a skip rate above some threshold) be able to produce a non-zero exit code, at least in --ci mode? If so, which exit code (ExitError? a new one?) and under what threshold (any skip? all files skipped? a percentage?).

Actual behavior

SkippedFiles is purely informational. A run where 100% of files fail to be analyzed (for any per-file infrastructure reason) is indistinguishable, by exit code, from a clean run with zero violations.

Acceptance criteria

• A decision is made and recorded (ADR if it's architecturally significant) on whether/how skipped-file counts affect the exit code
• If a behavior change is decided, it's implemented consistently across all three skip causes (fetchContext, CreateEmbedding, Search) — not just Search
• Regression test added covering the chosen behavior