Mod API: a mod can implement the key hook

mod_api re-exported winit::event::KeyEvent, which shadowed the generated
KeyEvent<'_> that Hooks::key takes, so a mod crate could not name key's event.
mod_api now re-exports winit itself, as it does serde_json, and a test builds a
mod-side Hooks with key and input_key.

crates/horizon-client/Cargo.toml

@@ -130,6 +130,10 @@ path = "src/main.rs"
 name = "launch_api"
 path = "tests/launch_api.rs"
 
+[[test]]
+name = "mod_api_hooks"
+path = "tests/mod_api_hooks.rs"
+
 [lints]
 workspace = true
 

crates/horizon-client/src/mod_api.rs

@@ -50,7 +50,8 @@ pub use horizon_world::{
 pub use serde_json;
 use serde_json::{Map, Value};
 use std::time::Duration;
-pub use winit::event::KeyEvent;
+/// The window events `input_key` hands over (`winit::event::KeyEvent`) and their key types.
+pub use winit;
 
 /// A dispenser hook's answer: the slot's remainder (None empties it) and the
 /// level event to play, `CLICK` (1000), `FAIL` (1001) or 0 for none.

crates/horizon-client/tests/mod_api_hooks.rs

@@ -0,0 +1,20 @@
+//! A mod crate's view of the mod API: `Hooks` is implemented with the names `mod_api` exports.
+//! The test is that this file builds; #7044's mod could not name `key`'s event.
+use horizon_client::mod_api::{Hooks, Host, InputKeyEvent, KeyEvent, winit};
+
+struct Keys;
+
+impl Hooks for Keys {
+    fn key(&self, _host: &mut dyn Host, event: &mut KeyEvent<'_>) {
+        let _ = (event.key, event.pressed);
+    }
+
+    fn input_key(&self, _host: &mut dyn Host, event: &mut InputKeyEvent<'_>) {
+        let _: &winit::event::KeyEvent = event.event;
+    }
+}
+
+#[test]
+fn a_mod_implements_the_key_hooks() {
+    let _: Box<dyn Hooks> = Box::new(Keys);
+}