test: guard the generated Collection impl for camelCase record NSIDs

`cargo build` does not compile the test target, so nothing catches codegen
dropping a `Collection` impl. #345 fixed exactly that: `app.bsky.actor.
contentVisibilityDeclaration` is the first record whose NSID leaf is
camelCase, and the NSID was rebuilt from the snake_case'd file stem, so the
record never matched its own schema and got no `Collection` impl.
`KnownRecord` is keyed on schema ids, so it *did* gain the variant, leaving
downstream crates with an arm they could not satisfy.

Two assertions, neither coupled to lexicon contents:

- Naming `ContentVisibilityDeclaration::NSID` requires the `Collection`
  impl to exist; comparing it against the literal requires it to carry the
  NSID verbatim rather than a mangled form.
- A never-called function taking `<ContentVisibilityDeclaration as
  Collection>::Record` and returning the corresponding `KnownRecord`
  variant asserts at compile time that the two halves agree on the record
  type. Drifting the associated type fails to build here while the NSID
  assertions still pass, so this catches a case the runtime checks cannot.

Verified by reintroducing the #345 breakage against the current tree:
deleting the `Collection` impl fails the test target to compile, as does
pointing its `Record` at a different record type.

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

Author: knasher

atrium-api/tests/codegen_fidelity.rs

@@ -0,0 +1,39 @@
+//! Fidelity tests for the code generated by `atrium-codegen`.
+//!
+//! These assert properties of the *generated code itself* — the shape of the
+//! `Collection` impl and its agreement with `KnownRecord` — so they are not
+//! coupled to the contents of any particular lexicon revision.
+
+#![cfg(feature = "namespace-appbsky")]
+
+use atrium_api::app::bsky::actor::ContentVisibilityDeclaration;
+use atrium_api::record::KnownRecord;
+use atrium_api::types::Collection;
+
+/// `app.bsky.actor.contentVisibilityDeclaration` is the first record whose NSID
+/// leaf is camelCase, and it broke an assumption in codegen: the NSID was
+/// rebuilt from the snake_case'd file stem, so the record never matched its own
+/// schema and got no `Collection` impl. `KnownRecord` is keyed on schema ids, so
+/// it *did* gain the variant — leaving downstream crates with an arm they could
+/// not satisfy.
+#[test]
+fn camel_case_record_nsid_is_generated_verbatim() {
+    const NSID: &str = "app.bsky.actor.contentVisibilityDeclaration";
+
+    // Naming `NSID` at all requires the `Collection` impl to exist; the
+    // assertions require it to carry the NSID verbatim, rather than a
+    // snake_case'd or otherwise mangled form.
+    assert_eq!(ContentVisibilityDeclaration::NSID, NSID);
+    assert_eq!(ContentVisibilityDeclaration::nsid().as_str(), NSID);
+}
+
+/// The `Collection` and `KnownRecord` halves must *agree* on the record type,
+/// not merely both exist. This is never called: it is a compile-time assertion,
+/// and fails to build if the `Collection` impl disappears again or its `Record`
+/// drifts from the type the corresponding `KnownRecord` variant holds.
+#[allow(dead_code)]
+fn collection_record_is_the_known_record_payload(
+    record: <ContentVisibilityDeclaration as Collection>::Record,
+) -> KnownRecord {
+    KnownRecord::AppBskyActorContentVisibilityDeclaration(Box::new(record))
+}