`eww logs` stays empty unless the daemon was started from a terminal (log redirection gated on isatty)

Checklist before submitting an issue

• I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
• I have specifically verified that this bug is not a common user error
• I am providing as much relevant information as I am able to in this bug report

Description of the bug

eww logs shows nothing — ever — when the daemon wasn't started from an interactive terminal, which is how most people run eww (compositor autostart like Hyprland's exec-once, a launcher script, systemd, or anything that redirects output).

Root cause: do_detach (crates/eww/src/server.rs) only redirects the detached daemon's stdout/stderr into the log file if they are a tty:

if nix::unistd::isatty(1)? {
    nix::unistd::dup2(fd, std::io::stdout().as_raw_fd())?;
}
if nix::unistd::isatty(2)? {
    nix::unistd::dup2(fd, std::io::stderr().as_raw_fd())?;
}

When the daemon is spawned with its stdio pointing at a pipe or /dev/null (the compositor/launcher case), both checks are false, nothing is redirected, and every runtime diagnostic — including the nicely formatted expression/type errors like Failed to turn 'null' into a value of type bool — goes to a fd nobody reads. The log file is created but stays 0 bytes forever, while the startup banner explicitly says Run 'eww logs' to see any errors while editing your configuration.

This makes runtime errors effectively invisible in exactly the setups where the terminal isn't available as a fallback — widgets silently don't update and there is nothing to debug with.

Reproducing the issue

$ eww daemon > /dev/null 2>&1        # anything non-tty: exec-once, a script, a pipe…
$ eww open some-window-with-an-expression-error
$ # trigger any update-time expression error (e.g. a deflisten emitting a value
$ # that makes `:visible {feed.x}` evaluate null)
$ eww logs
$ # → nothing. The log file at ~/.cache/eww/eww_<id>.log is 0 bytes.

Same sequence with eww daemon started from an interactive terminal: the errors appear in the log file as expected (isatty is true, so the redirect happens).

Expected behaviour

Diagnostics reach the log file regardless of how the daemon was spawned, so eww logs works for compositor/launcher setups. After the double fork there is no controlling terminal to preserve anyway — unconditional redirection is the standard daemon behavior.

Additional context

Verified on the v0.6.0 release binary and current master (48f5aa8). With the redirect made unconditional, the same detached-daemon sequence produces a populated log file (INFO lines plus the expression errors) and eww logs shows them. PR incoming.