feat: implement fuzzy search and replace functionality with Levenshtein distance

- Added `applySearchReplace` function to handle search and replace operations with fuzzy matching capabilities.
- Introduced tests for various scenarios including fuzzy matching with typos, exact matches, and handling whitespace differences.
- Created a parser for search/replace blocks to facilitate the new functionality.
- Updated prompts for search-replace operations to clarify usage and examples.
- Added utility functions for text normalization and language detection based on file extensions.
- Implemented a minimal stdio MCP server for local testing with tools for adding numbers and printing environment variables.

e2e-tests/fixtures/azure/basic.md

@@ -0,0 +1 @@
+This is a simple basic response

e2e-tests/fixtures/engine/read-index.md

@@ -0,0 +1,3 @@
+Read the index page:
+<dyad-read path="src/pages/Index.tsx"></dyad-read>
+Done.

e2e-tests/fixtures/engine/turbo-edits-v2-trigger-fallback.md

@@ -0,0 +1,10 @@
+Example with turbo edit v2
+<dyad-search-replace path="src/pages/Index.tsx">
+<<<<<<< SEARCH
+        // Intentionally DO NOT MATCH ANYTHING TO TRIGGER FALLBACK
+        <h1 className="text-4xl font-bold mb-4">Welcome to Your Blank App</h1>
+=======
+        <h1 className="text-4xl font-bold mb-4">Welcome to the UPDATED App</h1>
+>>>>>>> REPLACE
+</dyad-search-replace>
+End of turbo edit

e2e-tests/fixtures/engine/turbo-edits-v2.md

@@ -0,0 +1,9 @@
+Example with turbo edit v2
+<dyad-search-replace path="src/pages/Index.tsx">
+<<<<<<< SEARCH
+        <h1 className="text-4xl font-bold mb-4">Welcome to Your Blank App</h1>
+=======
+        <h1 className="text-4xl font-bold mb-4">Welcome to the UPDATED App</h1>
+>>>>>>> REPLACE
+</dyad-search-replace>
+End of turbo edit

e2e-tests/fixtures/engine/update-index-1.md

@@ -0,0 +1,4 @@
+First read
+<dyad-write path="src/pages/Index.tsx" description="replace file">
+// this file has been replaced
+</dyad-write>

e2e-tests/fixtures/import-app/context-manage/manual/baz.json

@@ -1 +1 @@
-["should not be included b/c it's json"]
+["even json is included"]

e2e-tests/fixtures/security-review/findings.md

@@ -0,0 +1,132 @@
+OK, let's review the security.
+
+Here are variations with different severity levels.
+
+Purposefully putting medium on top to make sure the severity levels are sorted correctly.
+
+## Medium Severity
+
+<dyad-security-finding title="Unvalidated File Upload Extensions" level="medium">
+**What**: The file upload endpoint accepts any file type without validating extensions or content, only checking file size
+
+**Risk**: An attacker could upload malicious files (e.g., .exe, .php) that might be executed if the server is misconfigured, or upload extremely large files to consume storage space
+
+**Potential Solutions**: 
+1. Implement a whitelist of allowed file extensions (e.g., `.jpg`, `.png`, `.pdf`)
+2. Validate file content type using magic numbers, not just the extension
+3. Store uploaded files outside the web root with random filenames
+4. Implement virus scanning for uploaded files using ClamAV or similar
+
+**Relevant Files**: `src/api/upload.ts`
+
+</dyad-security-finding>
+
+<dyad-security-finding title="Missing CSRF Protection on State-Changing Operations" level="medium">
+**What**: POST, PUT, and DELETE endpoints don't implement CSRF tokens, making them vulnerable to cross-site request forgery attacks
+
+**Risk**: An attacker could trick authenticated users into unknowingly performing actions like changing their email, making purchases, or deleting data by visiting a malicious website
+
+**Potential Solutions**: 
+1. Implement CSRF tokens using a library like `csurf` for Express
+2. Set `SameSite=Strict` or `SameSite=Lax` on session cookies
+3. Verify the `Origin` or `Referer` header for sensitive operations
+4. For API-only applications, consider using custom headers that browsers can't set cross-origin
+
+**Relevant Files**: `src/middleware/auth.ts`, `src/api/*.ts`
+
+</dyad-security-finding>
+
+## Critical Severity
+
+<dyad-security-finding title="SQL Injection in User Lookup" level="critical">
+**What**: User input flows directly into database queries without validation, allowing attackers to execute arbitrary SQL commands
+
+**Risk**: An attacker could steal all customer data, delete your entire database, or take over admin accounts by manipulating the URL
+
+**Potential Solutions**: 
+1. Use parameterized queries: `db.query('SELECT * FROM users WHERE id = ?', [userId])`
+2. Add input validation to ensure `userId` is a number
+3. Implement an ORM like Prisma or TypeORM that prevents SQL injection by default
+
+**Relevant Files**: `src/api/users.ts`
+
+</dyad-security-finding>
+
+<dyad-security-finding title="Hardcoded AWS Credentials in Source Code" level="critical">
+**What**: AWS access keys are stored directly in the codebase and committed to version control, exposing full cloud infrastructure access
+
+**Risk**: Anyone with repository access (including former employees or compromised accounts) could spin up expensive resources, access S3 buckets with customer data, or destroy production infrastructure
+
+**Potential Solutions**: 
+1. Immediately rotate the exposed credentials in AWS IAM
+2. Use environment variables and add `.env` to `.gitignore`
+3. Implement AWS Secrets Manager or similar vault solution
+4. Scan git history and purge the credentials using tools like `git-filter-repo`
+
+**Relevant Files**: `src/config/aws.ts`, `src/services/s3-uploader.ts`
+
+</dyad-security-finding>
+
+## High Severity
+
+<dyad-security-finding title="Missing Authentication on Admin Endpoints" level="high">
+**What**: Administrative API endpoints can be accessed without authentication, relying only on URL obscurity
+
+**Risk**: An attacker who discovers these endpoints could modify user permissions, access sensitive reports, or change system configurations without credentials
+
+**Potential Solutions**: 
+1. Add authentication middleware to all `/admin/*` routes
+2. Implement role-based access control (RBAC) to verify admin permissions
+3. Add audit logging for all administrative actions
+4. Consider implementing rate limiting on admin endpoints
+
+**Relevant Files**: `src/api/admin/users.ts`, `src/api/admin/settings.ts`
+
+</dyad-security-finding>
+
+<dyad-security-finding title="JWT Secret Using Default Value" level="high">
+**What**: The application uses a hardcoded default JWT secret ("your-secret-key") for signing authentication tokens
+
+**Risk**: Attackers can forge valid JWT tokens to impersonate any user, including administrators, granting them unauthorized access to user accounts and sensitive data
+
+**Potential Solutions**: 
+1. Generate a strong random secret: `openssl rand -base64 32`
+2. Store the secret in environment variables
+3. Rotate the JWT secret, which will invalidate all existing sessions
+4. Consider using RS256 (asymmetric) instead of HS256 for better security
+
+**Relevant Files**: `src/auth/jwt.ts`
+
+</dyad-security-finding>
+
+## Low Severity
+
+<dyad-security-finding title="Verbose Error Messages Expose Stack Traces" level="low">
+**What**: Production error responses include full stack traces and internal file paths that are sent to end users
+
+**Risk**: Attackers can use this information to map your application structure, identify frameworks and versions, and find potential attack vectors more easily
+
+**Potential Solutions**: 
+1. Configure different error handlers for production vs development
+2. Log detailed errors server-side but send generic messages to clients
+3. Use an error handling middleware: `if (process.env.NODE_ENV === 'production') { /* hide details */ }`
+4. Implement centralized error logging with tools like Sentry
+
+**Relevant Files**: `src/middleware/error-handler.ts`
+
+</dyad-security-finding>
+
+<dyad-security-finding title="Missing Security Headers" level="low">
+**What**: The application doesn't set recommended security headers like `X-Frame-Options`, `X-Content-Type-Options`, and `Strict-Transport-Security`
+
+**Risk**: Users may be vulnerable to clickjacking attacks, MIME-type sniffing, or man-in-the-middle attacks, though exploitation requires specific conditions
+
+**Potential Solutions**: 
+1. Use Helmet.js middleware: `app.use(helmet())`
+2. Configure headers manually in your web server (nginx/Apache) or application
+3. Set `Content-Security-Policy` to prevent XSS attacks
+4. Enable HSTS to enforce HTTPS connections
+
+**Relevant Files**: `src/app.ts`, `nginx.conf`
+
+</dyad-security-finding>