codegen: generate does not check CodeGenConfig::extern_paths, so a direct caller's malformed proto name is kept and never matches a type #703

Follows #677, which added buffa_codegen::normalize_extern_path_proto_name and calls it from the protoc-gen-buffa option parser and from buffa_build::Config::compile. A caller that fills CodeGenConfig::extern_paths and calls generate or generate_with_diagnostics itself is not covered:

let mut config = buffa_codegen::CodeGenConfig::default();
config.extern_paths.push(("my.common".into(), "::common_protos".into()));   // leading dot left off
config.extern_paths.push((".my..common".into(), "::common_protos".into())); // empty segment
let files = buffa_codegen::generate(&descriptors, &to_generate, &config)?;

Both entries are kept as given. resolve_extern_prefix and resolve_extern_type (buffa-codegen/src/context.rs) compare each entry with a dotted name such as .my.common, so these two never match a type. generate succeeds, references to the types of my.common get the local module path instead of ::common_protos, and the build does not report the unused mapping. The extern_paths rustdoc from #677 states the gap: "generate does not validate entries, and an entry in another form matches no type".

exclude_packages already has the check in codegen: generate_with_diagnostics (buffa-codegen/src/lib.rs) passes each entry through normalize_exclude_package and returns CodeGenError::Other for a malformed one, with the comment "this is the one place a direct CodeGenConfig caller's entries are checked".

Expected: generate_with_diagnostics passes each extern_paths proto name through normalize_extern_path_proto_name in the same place and returns an error that quotes the entry. The two front ends keep their earlier check, so their users see the error before protoc runs.