SULO Schema Builder v0.1.1

Hide the Windows console, bind the API to loopback (v0.1.1)

Two problems reported from the v0.1.0 Windows build.

A console window sat behind the app. Not the sidecar — tauri-plugin-shell
already suppresses that one — but the Tauri process itself: main.rs had no
windows_subsystem attribute, so the binary linked as a console-subsystem
app and Windows allocated a console for it. `cargo tauri build` doesn't add
this; the stock template does and ours never had it. Gated on
not(debug_assertions) so `cargo tauri dev` keeps its console.

That attribute removes stdout from Windows release builds, which would have
silently discarded the sidecar's output — the only diagnostic trail for the
Java discovery, ROBOT download and SULO refresh that all run at startup and
can all fail. So the drain now also writes to sulo-schema-builder.log in
the app-data dir next to sulo.db, truncated each launch so it stays bounded
without a rotation scheme. The path rule is duplicated from config.ts's
appDataDir because the sidecar is a separate process; the two must not
drift.

The firewall prompt was index.ts hardcoding 0.0.0.0. Windows prompts the
first time a program listens on a non-loopback interface, and macOS asks
the same question — so this was never Windows-specific, Linux just doesn't
ask. Worth fixing regardless of the prompt: the desktop app was serving its
unauthenticated REST API, and so the user's whole schema database, to every
machine on the local network. HOST now defaults to 127.0.0.1, with
0.0.0.0 set explicitly in docker-compose.yml and both Dockerfile stages —
without which a container would be unreachable through its published port.

Verified: loopback serves while the LAN address is refused, and HOST=0.0.0.0
restores both. `cargo check` passes. The Windows symptoms themselves can
only be confirmed from a Windows build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ADCi8dinwMj13AuRNEtQmM