feat: Implement `same` Daemon for Persistent Background Execution

[drlucaa]

Currently, same operates as an ephemeral CLI that must perform expensive operations—such as Nix environment hydration, recursive file hashing, and dependency graph calculation—from scratch or via disk-based cache on every run.

This issue proposes the creation of a persistent background daemon, similar to the nx daemon. The daemon will reside in the background to maintain an in-memory cache of resolved Nix environments and use file-watching to proactively update input hashes. This will significantly reduce the "Time to Build" for developers by eliminating the startup overhead of the execution engine.

Goals

• Persistent Environment Caching: Move the EnvFactory cache from a file-per-environment strategy into a long-lived memory store to eliminate JSON I/O latency.
• Proactive Hashing: Implement a file-watching mechanism that triggers the Hasher to re-calculate input fingerprints as files change, rather than waiting for a same run command.
• Optimized Dependency Graph: Cache the Graph structure in memory and only invalidate it when configuration files (same.yaml or same.work.yaml) are modified.
• Hermetic Communication: Establish a communication protocol between the CLI and Daemon using gRPC over Unix Domain Sockets (UDS) to ensure zero-network dependency.

Acceptance Criteria

1. Architectural Integrity

• Create a new Daemon port in internal/core/ports/daemon.go following Clean Architecture principles.
• Implement the daemon as a dedicated adapter in internal/adapters/daemon that does not depend on the app or engine layers.

2. Daemon Lifecycle

• The CLI must automatically spawn the daemon if it is not running.
• The daemon must implement an auto-shutdown mechanism after a configurable period of inactivity (default: 3 hours).
• Communication must be strictly restricted to Unix Domain Sockets to maintain build hermeticity.

3. Execution Engine Refactor

• Refactor the Scheduler to support a "Remote" mode where task execution requests are delegated to the daemon via gRPC streams.
• The daemon must stream real-time task logs (stdout/stderr) back to the CLI's Renderer to preserve the TUI experience.

4. Verification & Standards

• Must utilize Go 1.25+ features, specifically unique for interning path strings and iter.Seq for graph traversals.
• Concurrency and timeout logic must be verified using testing/synctest.