daemon: tolerate BrokenPipe on ready(); i2cd: handle empty RON response

daemon/src/lib.rs: Daemon::ready() previously called .unwrap() on the
init pipe write, causing a panic with BrokenPipe when init had already
closed its read end during the startup phase. Daemons like i2c-gpio-expanderd,
intel-gpiod, dw-acpi-i2cd, and i2c-hidd hit this in redbear-mini boots.
Now BrokenPipe is silently ignored — the daemon is operational regardless
of init's readiness tracking state.

drivers/usb/ucsid/src/main.rs and drivers/gpio/i2c-gpio-expanderd/src/main.rs:
read_i2c_control_response() returned an empty buffer (no I2C adapters
registered) and then tried ron::from_str('') which failed at 1:1 with
'Unexpected end of RON'. This produced false-positive warnings on every
boot where no I2C hardware is present. Now an empty/whitespace response
returns AdapterList(Vec::new()) gracefully.

drivers/usb/ucsid/src/main.rs

@@ -785,7 +785,11 @@ fn read_i2c_control_response(file: &mut File) -> Result<I2cControlResponse> {
         .context("failed to read I2C control response")?;
     buffer.truncate(count);
     let text = std::str::from_utf8(&buffer).context("I2C control response was not UTF-8")?;
-    ron::from_str(text).context("failed to decode I2C control response")
+    let trimmed = text.trim();
+    if trimmed.is_empty() {
+        return Ok(I2cControlResponse::AdapterList(Vec::new()));
+    }
+    ron::from_str(trimmed).context("failed to decode I2C control response")
 }
 
 fn read_symbol_id(path: &Path) -> Result<Option<String>> {