Function check_annotations 

pub fn check_annotations(
    file: FileId,
    hir: &HirFile,
    index: &SymbolIndex,
    manifest: Option<&HostManifest>,
    scope: &ImportScope,
) -> Vec<Diagnostic>

Semantic diagnostics on annotation content: unknown type names (E061). Brink-dialect-only (see module doc). manifest: the registered host manifest, if any — T1d-2’s Handle<K> vocabulary source (None degrades to an empty handle-kind set, same posture as every other manifest-driven check).

Issue #2272: a bare Named annotation’s struct-name check is referrer-scoped, mirroring resolve::resolve_type_ref’s own ImportScope/Candidacy semantics (this file’s check_one’s own doc has the detail) — names.structs itself stays the project-flat set [TypeNames::new] always built (unchanged consumer: resolve’s Ty::Struct resolution and structs::declared_shapes’s field-type resolution both still want “declared anywhere”, not “visible from here” — see [check_one]’s doc for the full accounting of which consumer gets which view).

scope: the referrer’s own declared-module ImportScope, caller- supplied rather than derived here from hir.module/hir.imports in isolation. An earlier version of this fix built its own per-file scope exactly that way (mirroring structs::check_assignments’s own construction) and called it a brink-analyzer::annotations-only change — that claim did NOT survive contact with the full gate: hir.module only ever carries an explicit #@module(...) directive, but a native file’s real declared module is path-derived (analyze_with_modules’s own doc: “a native file’s hir.module carries a deliberately empty name… and would otherwise scope the file to the module named \"\"” — never None, so the naive derivation silently excluded a native file’s own siblings, including the mounted stdlib’s own internal same-module references, misfiring E061 in std/conventions/ screenplay.brink itself). The correct scope is only ever resolvable with the project’s real [ModuleMap] (or brink-db’s module_map_query) in hand — see [per_file_diagnostics]’s own scope doc — so this DOES have a caller-side signature-plumbing footprint after all (per_file_diagnostics, finish_analysis, analyze_with_modules, and brink-db’s per_file_diagnostics_query), even though it never touches LIR lowering.

Takes exactly one file, not a slice (review finding on this PR): a single scope applied across a whole files: &[(FileId, &HirFile)] slice would silently apply file A’s import scope to file B’s annotations the moment a caller ever passed more than one entry — this crate already keys a scope per file correctly elsewhere (structs::check_assignments’s BTreeMap<FileId, ImportScope>). Every real and test caller here has only ever passed a single-file slice, so this narrows the signature to what’s actually true rather than widening it to a map with only ever one entry.