fix: harden workspace startup and daemon config handling

[ayomidelog]

Summary

This PR hardens workspace startup, fixes false-success networking behavior, removes shared-rootfs runtime leakage, makes daemon auto-start respect project config, and reduces the amount of manual Linux setup users need before enclave up / enclave down work.

What Changed

1. Fail workspace startup closed when networking is not actually ready

Workspace startup previously allowed a degraded success path where the workspace could be marked running even when outbound networking was not correctly attached.

This PR changes startup semantics so that:

• networking setup is treated as required for a successful startup
• workspace startup aborts if Enclave cannot attach networking
• startup also aborts if a usable default route is not present in the workspace network namespace

This directly addresses the observed case where enclave up could succeed while the workspace had no usable outbound route.

2. Fix the default-route readiness check

The readiness probe now validates the actual default route state more reliably by inspecting ip route show default and matching the expected interface and gateway.

During verification, this also exposed a false-negative path in the earlier probe logic, which is now corrected.

3. Stop mutating shared sandbox rootfs for runtime workspace files

Runtime networking-related files are now provisioned against the live workspace root instead of the shared sandbox rootfs.

This includes:

• resolv.conf
• /etc/hosts
• apt sandbox override state

That prevents workspace-specific runtime state from leaking across sibling workspaces.

4. Make registry mutation fail closed on invalid state

Mutating registry operations no longer silently replace corrupt registry contents with an empty in-memory registry.

Instead:

• ordinary mutation fails closed when registry state is invalid
• explicit registry repair remains the supported recovery path

This avoids accidental state loss when registry contents are malformed or partially written.

5. Fix session helper resolution outside daemon-only flows

Workspace session helper resolution previously depended on copying the current process image. That breaks when startup is driven from a non-daemon process such as test binaries or other library-driven flows.

This PR resolves the actual enclave binary more robustly by:

• honoring explicit helper overrides
• using Cargo-provided binary paths when available
• inferring the sibling target/<profile>/enclave binary when current execution happens under target/<profile>/deps

That restores internal workspace-session launch behavior for integration and test-driven startup paths.

6. Make daemon auto-start honor project configuration

Commands that implicitly start the daemon now use the configured values instead of silently falling back to global defaults.

Auto-start now respects:

• state_dir
• pid_file
• debootstrap_binary
• configured security defaults such as AppArmor and SELinux labels
• configured daemon wait timeout

This prevents commands from connecting to the right socket while starting a daemon with the wrong state/runtime paths.

7. Reduce manual root-owned path setup friction

When root launches Enclave against private runtime/state directories created by the invoking user, Enclave now repairs ownership and permissions for those private service directories instead of failing immediately and requiring manual chown / permission repair first.

This improves the real-world enclave up / enclave down UX for project-local configuration without weakening the secure-directory checks.

8. Tighten auth provider visibility

Configured auth providers are now only reported as configured when their token files actually pass permission and ownership validation.

Ownership validation is also aligned with the effective user managing the state directory instead of assuming a hardcoded uid 0 path for all cases.

User-Facing Impact

After this change:

• enclave up should no longer report success when the workspace lacks a valid outbound route
• users are less likely to hit avoidable runtime/state-dir ownership errors during daemon startup
• project-local config is honored consistently when the daemon is started implicitly
• runtime workspace files no longer leak through the shared sandbox rootfs
• enclave down continues to stop the running workspace runtime and terminate long-lived processes inside it

Verification

Build and static checks

• cargo check --all-targets
• cargo clippy --all-targets -- -D warnings

Default test suite

• cargo test --all-targets -- --skip integration:: --skip stress::

Root integration coverage

• sudo env ... cargo test --test integration_suite -- --ignored --test-threads=1

This root integration run covered:

• sandbox lifecycle
• workspace lifecycle
• workspace auth injection into the live workspace root
• host mount behavior
• snapshot/restore behavior
• cgroup limit application
• network-dependent workspace startup

End-to-end CLI verification

Direct CLI runs were executed against disposable Enclavefile-backed projects to verify:

• enclave up
• enclave down
• successful startup with project-configured state/runtime paths
• successful startup even when those private directories were initially user-owned
• process termination behavior inside the workspace after enclave down

Why This PR Exists

The main trigger for this work was a correctness bug where:

• enclave up could succeed
• the workspace existed and accepted commands
• outbound networking still failed because no usable non-loopback default route was actually available

This PR changes that behavior so success means networking is actually attached and route-ready, not merely that the workspace process exists.