Phase 2: Implement Execution Environment Abstraction (v0.3.0)

This commit implements Phase 2 of the CHORUS Task Execution Engine development plan,
providing a comprehensive execution environment abstraction layer with Docker
container sandboxing support.

## New Features

### Core Sandbox Interface
- Comprehensive ExecutionSandbox interface with isolated task execution
- Support for command execution, file I/O, environment management
- Resource usage monitoring and sandbox lifecycle management
- Standardized error handling with SandboxError types and categories

### Docker Container Sandbox Implementation
- Full Docker API integration with secure container creation
- Transparent repository mounting with configurable read/write access
- Advanced security policies with capability dropping and privilege controls
- Comprehensive resource limits (CPU, memory, disk, processes, file handles)
- Support for tmpfs mounts, masked paths, and read-only bind mounts
- Container lifecycle management with proper cleanup and health monitoring

### Security & Resource Management
- Configurable security policies with SELinux, AppArmor, and Seccomp support
- Fine-grained capability management with secure defaults
- Network isolation options with configurable DNS and proxy settings
- Resource monitoring with real-time CPU, memory, and network usage tracking
- Comprehensive ulimits configuration for process and file handle limits

### Repository Integration
- Seamless repository mounting from local paths to container workspaces
- Git configuration support with user credentials and global settings
- File inclusion/exclusion patterns for selective repository access
- Configurable permissions and ownership for mounted repositories

### Testing Infrastructure
- Comprehensive test suite with 60+ test cases covering all functionality
- Docker integration tests with Alpine Linux containers (skipped in short mode)
- Mock sandbox implementation for unit testing without Docker dependencies
- Security policy validation tests with read-only filesystem enforcement
- Resource usage monitoring and cleanup verification tests

## Technical Details

### Dependencies Added
- github.com/docker/docker v28.4.0+incompatible - Docker API client
- github.com/docker/go-connections v0.6.0 - Docker connection utilities
- github.com/docker/go-units v0.5.0 - Docker units and formatting
- Associated Docker API dependencies for complete container management

### Architecture
- Interface-driven design enabling multiple sandbox implementations
- Comprehensive configuration structures for all sandbox aspects
- Resource usage tracking with detailed metrics collection
- Error handling with retryable error classification
- Proper cleanup and resource management throughout sandbox lifecycle

### Compatibility
- Maintains backward compatibility with existing CHORUS architecture
- Designed for future integration with Phase 3 Core Task Execution Engine
- Extensible design supporting additional sandbox implementations (VM, process)

This Phase 2 implementation provides the foundation for secure, isolated task
execution that will be integrated with the AI model providers from Phase 1
in the upcoming Phase 3 development.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

vendor/github.com/felixge/httpsnoop/capture_metrics.go

@@ -0,0 +1,86 @@
+package httpsnoop
+
+import (
+	"io"
+	"net/http"
+	"time"
+)
+
+// Metrics holds metrics captured from CaptureMetrics.
+type Metrics struct {
+	// Code is the first http response code passed to the WriteHeader func of
+	// the ResponseWriter. If no such call is made, a default code of 200 is
+	// assumed instead.
+	Code int
+	// Duration is the time it took to execute the handler.
+	Duration time.Duration
+	// Written is the number of bytes successfully written by the Write or
+	// ReadFrom function of the ResponseWriter. ResponseWriters may also write
+	// data to their underlaying connection directly (e.g. headers), but those
+	// are not tracked. Therefor the number of Written bytes will usually match
+	// the size of the response body.
+	Written int64
+}
+
+// CaptureMetrics wraps the given hnd, executes it with the given w and r, and
+// returns the metrics it captured from it.
+func CaptureMetrics(hnd http.Handler, w http.ResponseWriter, r *http.Request) Metrics {
+	return CaptureMetricsFn(w, func(ww http.ResponseWriter) {
+		hnd.ServeHTTP(ww, r)
+	})
+}
+
+// CaptureMetricsFn wraps w and calls fn with the wrapped w and returns the
+// resulting metrics. This is very similar to CaptureMetrics (which is just
+// sugar on top of this func), but is a more usable interface if your
+// application doesn't use the Go http.Handler interface.
+func CaptureMetricsFn(w http.ResponseWriter, fn func(http.ResponseWriter)) Metrics {
+	m := Metrics{Code: http.StatusOK}
+	m.CaptureMetrics(w, fn)
+	return m
+}
+
+// CaptureMetrics wraps w and calls fn with the wrapped w and updates
+// Metrics m with the resulting metrics. This is similar to CaptureMetricsFn,
+// but allows one to customize starting Metrics object.
+func (m *Metrics) CaptureMetrics(w http.ResponseWriter, fn func(http.ResponseWriter)) {
+	var (
+		start         = time.Now()
+		headerWritten bool
+		hooks         = Hooks{
+			WriteHeader: func(next WriteHeaderFunc) WriteHeaderFunc {
+				return func(code int) {
+					next(code)
+
+					if !(code >= 100 && code <= 199) && !headerWritten {
+						m.Code = code
+						headerWritten = true
+					}
+				}
+			},
+
+			Write: func(next WriteFunc) WriteFunc {
+				return func(p []byte) (int, error) {
+					n, err := next(p)
+
+					m.Written += int64(n)
+					headerWritten = true
+					return n, err
+				}
+			},
+
+			ReadFrom: func(next ReadFromFunc) ReadFromFunc {
+				return func(src io.Reader) (int64, error) {
+					n, err := next(src)
+
+					headerWritten = true
+					m.Written += n
+					return n, err
+				}
+			},
+		}
+	)
+
+	fn(Wrap(w, hooks))
+	m.Duration += time.Since(start)
+}