refactor!: move verification support out of semantic crate

[e54-bot]

Fixes #152

Summary

• move census, conformance, and live-capture support into workshop-rs-cli tooling
• keep real-project expectations and provenance beside feature-owned tests and fixtures
• remove the semantic crate's standalone evidence module and update architecture documentation

Release

This intentionally removes released workshop_rs::{census, conformance, live_capture, real_projects} paths as a breaking library API change. The branch keeps workspace and package versions at 0.1.20 so merging the feature PR does not bypass the release-plz Release PR gate. Its refactor!: commit and BREAKING CHANGE: footer make release-plz propose the next 0.2.0 Release PR.

Verification

• cargo fmt --all --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace --all-targets
• cargo run -p workshop-rs --bin workshop-catalog-gen -- check
• independent ablation confirmed CLI integration tests depend on the public tooling boundary

[Teakowa]

crates/workshop-rs/src/lib.rs: this removes the released public modules census, conformance, live_capture, and real_projects. v0.1.20 exposed these paths, and ADR-0002 treated workshop_rs::conformance as a canonical public contract; meanwhile release-plz.toml has semver_check = false. This can turn #152 into an unversioned breaking library API change. Preserve compatibility for the released paths, or explicitly authorize/version the breaking contract before merging.

Superseded by a clarified review: the project decision is to keep the #152 ownership/layout change and version it as an intentional breaking API change, rather than leaving the choice to the implementation agent.

[Teakowa]

crates/workshop-rs/src/lib.rs: keep the #152 ownership/layout change and remove the released workshop_rs::{census, conformance, live_capture, real_projects} paths, but treat this as an intentional breaking library API change. The current release line is 0.1.20 and release-plz.toml has semver_check = false, so this must not ship as an ordinary refactor/patch release. Update the release/versioning contract for this change to the 0.2.0 line.

[Teakowa]

The previous API-versioning finding is not fully fixed. Do not bump the workspace/package versions to 0.2.0 in this feature PR: the repository runs release-plz release on every push to main, so merging an already-unpublished 0.2.0 would publish/tag it immediately and bypass the normal release-PR review gate. Revert the manual Cargo.toml/Cargo.lock version bump and mark the change that lands on main as a Conventional Commit breaking change (refactor!: / BREAKING CHANGE:) so release-plz release-pr proposes the 0.2.0 line; the actual version bump should remain in the generated release PR.

[Teakowa]

LGTM