Propagate silently swallowed runtime failures

[devin-ai-integration]

Summary

Audited try? / empty-catch / let _ = sites and fixed the ones where a real failure was indistinguishable from success, empty output, or a normal end-of-stream. Intentional best-effort cleanup (try? removeItem, log rotation, etc.) was left alone.

Streaming transport lost its setup and read errors. UnixSocketHTTP.stream returned through onComplete whether it had connected or not, and a read() error was treated as EOF:

- guard let fd = try? Self.connectSocket(path) else { return }
- if count <= 0 { break }
+ do { fd = try Self.connectSocket(path) } catch { onFailure(error); return }
+ if count < 0 { onFailure(HTTPError.socket(Self.errnoMessage("read"))); break }

onFailure defaults to a no-op so existing callers are unchanged; the Docker consumers now use it — log streams yield an ERROR line, and build/pushImage yield Docker's own {"errorDetail":…} frame (which AppStore already renders as ERROR: …) instead of ending as an empty successful stream.

Docker log reads. logs(containerID:) turned any non-2xx into []; it now throws HTTPError.status. Consequently:

• AppStore.fetchLogs/fetchEnv set actionError instead of (try? …) ?? [], so the detail view no longer shows "no logs" for a failed request.
• The shim's /containers/{id}/logs returns 500 rather than an empty raw stream.
• AppStore.streamPodLogs yields a failure line when kubectl cannot even launch (previously catch { continuation.finish() }).

TLS proxy degradation was unobservable. refreshTLSProxyLocked swallowed both issuance and start failures, so HTTPS could silently fall back to HTTP-only for new domains. The reason is now retained and surfaced end-to-end: NetworkingStatus.httpsProxyError → XPC dictionary → DorydNetworkingStatus → HealthReporter's network.resources check (now warn with a dory repair domains --apply action). The rollback path also clears tlsProxy when restarting the previous listener fails, so status() can't report an HTTPS mode backed by a stopped proxy.

Health repair fallback hid the daemon's error. runRepairTarget used if …, let result = try? await dorydClient.repairSubsystem(target), so a thrown daemon error fell through to the CLI path and vanished. The CLI fallback still runs (the daemon may not be running), but its failure message now carries the daemon reason.

Terminal docker install reported success unconditionally. HostDockerCLI.install() returned true as long as the bundled helper existed, even if the symlink or every profile write failed; symlink/addToPath now report their outcome and install() returns whether docker is linked and on PATH.

Other: Finder materialization retry keeps the last underlying error (materializationIncomplete(items:reason:) instead of a bare providerUnavailable), and the non-Linux dory-agent smoke build now decodes the dispatcher probe response and fails on an RPC error instead of let _ = dispatch(…) printing "dispatcher OK".

Validation

cargo check/cargo fmt --check pass for dory-core (the changed main.rs arm is cfg(not(target_os = "linux")), checked by temporarily flipping the cfg locally). Swift build/tests need Apple Silicon macOS + Xcode per CONTRIBUTING.md and could not run here — scripts/build.sh / scripts/test.sh were not executed.

Link to Devin session: https://app.devin.ai/sessions/214208f8367e42aa9e53c1dab4fb99c6
Requested by: @Augani

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring