Index: frontend/node_modules/resolve/.github/FUNDING.yml
===================================================================
--- frontend/node_modules/resolve/.github/FUNDING.yml	(revision 9af201e94b5a79beb92a30858fc54de4bc3b9449)
+++ frontend/node_modules/resolve/.github/FUNDING.yml	(revision 9af201e94b5a79beb92a30858fc54de4bc3b9449)
@@ -0,0 +1,12 @@
+# These are supported funding model platforms
+
+github: [ljharb]
+patreon: # Replace with a single Patreon username
+open_collective: # Replace with a single Open Collective username
+ko_fi: # Replace with a single Ko-fi username
+tidelift: npm/resolve
+community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+liberapay: # Replace with a single Liberapay username
+issuehunt: # Replace with a single IssueHunt username
+otechie: # Replace with a single Otechie username
+custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
Index: frontend/node_modules/resolve/.github/INCIDENT_RESPONSE_PROCESS.md
===================================================================
--- frontend/node_modules/resolve/.github/INCIDENT_RESPONSE_PROCESS.md	(revision 9af201e94b5a79beb92a30858fc54de4bc3b9449)
+++ frontend/node_modules/resolve/.github/INCIDENT_RESPONSE_PROCESS.md	(revision 9af201e94b5a79beb92a30858fc54de4bc3b9449)
@@ -0,0 +1,119 @@
+# Incident Response Process for **resolve**
+
+## Reporting a Vulnerability
+
+We take the security of **resolve** very seriously. If you believe you’ve found a security vulnerability, please inform us responsibly through coordinated disclosure.
+
+### How to Report
+
+> **Do not** report security vulnerabilities through public GitHub issues, discussions, or social media.
+
+Instead, please use one of these secure channels:
+
+1. **GitHub Security Advisories**
+   Use the **Report a vulnerability** button in the Security tab of the [browserify/resolve repository](https://github.com/browserify/resolve).
+
+2. **Email**
+   Follow the posted [Security Policy](https://github.com/browserify/resolve/security/policy).
+
+### What to Include
+
+**Required Information:**
+- Brief description of the vulnerability type
+- Affected version(s) and components
+- Steps to reproduce the issue
+- Impact assessment (what an attacker could achieve)
+- Confirm the issue is not present in test files (in other words, only via the official entry points in `exports`)
+
+**Helpful Additional Details:**
+- Full paths of affected source files
+- Specific commit or branch where the issue exists
+- Required configuration to reproduce
+- Proof-of-concept code (if available)
+- Suggested mitigation or fix
+
+## Our Response Process
+
+**Timeline Commitments:**
+- **Initial acknowledgment**: Within 24 hours
+- **Detailed response**: Within 3 business days
+- **Status updates**: Every 7 days until resolved
+- **Resolution target**: 90 days for most issues
+
+**What We’ll Do:**
+1. Acknowledge your report and assign a tracking ID
+2. Assess the vulnerability and determine severity
+3. Develop and test a fix
+4. Coordinate disclosure timeline with you
+5. Release a security update and publish an advisory and CVE
+6. Credit you in our security advisory (if desired)
+
+## Disclosure Policy
+
+- **Coordinated disclosure**: We’ll work with you on timing
+- **Typical timeline**: 90 days from report to public disclosure
+- **Early disclosure**: If actively exploited
+- **Delayed disclosure**: For complex issues
+
+## Scope
+
+**In Scope:**
+- **resolve** package (all supported versions)
+- Official examples and documentation
+- Core resolution APIs
+- Dependencies with direct security implications
+
+**Out of Scope:**
+- Third-party wrappers or extensions
+- Bundler-specific integrations
+- Social engineering or physical attacks
+- Theoretical vulnerabilities without practical exploitation
+- Issues in non-production files
+
+## Security Measures
+
+**Our Commitments:**
+- Regular vulnerability scanning via `npm audit`
+- Automated security checks in CI/CD (GitHub Actions)
+- Secure coding practices and mandatory code review
+- Prompt patch releases for critical issues
+
+**User Responsibilities:**
+- Keep **resolve** updated
+- Monitor dependency vulnerabilities
+- Follow secure configuration guidelines for module resolution
+
+## Legal Safe Harbor
+
+**We will NOT:**
+- Initiate legal action
+- Contact law enforcement
+- Suspend or terminate your access
+
+**You must:**
+- Only test against your own installations
+- Not access, modify, or delete user data
+- Not degrade service availability
+- Not publicly disclose before coordinated disclosure
+- Act in good faith
+
+## Recognition
+
+- **Advisory Credits**: Credit in GitHub Security Advisories (unless anonymous)
+
+## Security Updates
+
+**Stay Informed:**
+- Subscribe to npm updates for **resolve**
+- Enable GitHub Security Advisory notifications
+
+**Update Process:**
+- Patch releases (e.g., 1.22.10 → 1.22.11)
+- Out-of-band releases for critical issues
+- Advisories via GitHub Security Advisories
+
+## Contact Information
+
+- **Security reports**: Security tab of [browserify/resolve](https://github.com/browserify/resolve/security)
+- **General inquiries**: GitHub Discussions or Issues
+
Index: frontend/node_modules/resolve/.github/THREAT_MODEL.md
===================================================================
--- frontend/node_modules/resolve/.github/THREAT_MODEL.md	(revision 9af201e94b5a79beb92a30858fc54de4bc3b9449)
+++ frontend/node_modules/resolve/.github/THREAT_MODEL.md	(revision 9af201e94b5a79beb92a30858fc54de4bc3b9449)
@@ -0,0 +1,74 @@
+## Threat Model for resolve (module path resolution library)
+
+### 1. Library Overview
+
+- **Library Name:** resolve
+- **Brief Description:** Implements Node.js `require.resolve()` algorithm for synchronous and asynchronous file path resolution. Used to locate modules and files in Node.js projects.
+- **Key Public APIs/Functions:** `resolve.sync()` / `resolve/sync`, `resolve()` / `resolve/async`
+
+### 2. Define Scope
+
+This threat model focuses on the core path resolution algorithm, including filesystem interaction, option handling, and cache management.
+
+### 3. Conceptual System Diagram
+
+```
+Caller Application → resolve(id, options) → Resolution Algorithm → File System
+                           │
+                           └→ Options Handling
+                           └→ Cache System
+```
+
+**Trust Boundaries:**
+- **Input module IDs:** May come from untrusted sources (user input, configuration)
+- **Filesystem access:** The library interacts with the filesystem to resolve paths
+- **Options:** Provided by the caller
+- **Cache:** Used to improve performance, but could be a vector for tampering or information disclosure if not handled securely
+
+### 4. Identify Assets
+
+- **Integrity of resolution output:** Ensure correct and safe file path matching.
+- **Confidentiality of configuration:** Prevent sensitive path information from being leaked.
+- **Availability/performance for host application:** Prevent crashes or resource exhaustion.
+- **Security of host application:** Prevent path traversal or unintended filesystem access.
+- **Reputation of library:** Maintain trust by avoiding supply chain attacks and vulnerabilities[1][3][4].
+
+### 5. Identify Threats
+
+| Component / API / Interaction                       | S  | T  | R  | I  | D  | E  |
+|-----------------------------------------------------|----|----|----|----|----|----|
+| Public API Call (`resolve/async`, `resolve/sync`)   | ✓  | ✓  | –  | ✓  | –  | –  |
+| Filesystem Access                                   | –  | ✓  | –  | ✓  | ✓  | –  |
+| Options Handling                                    | ✓  | ✓  | –  | ✓  | –  | –  |
+| Cache System                                        | –  | ✓  | –  | ✓  | –  | –  |
+
+**Key Threats:**
+- **Spoofing:** Malicious module IDs mimicking legitimate packages, or spoofing configuration options[1].
+- **Tampering:** Caller-provided paths altering resolution order, or cache tampering leading to incorrect results[1][4].
+- **Information Disclosure:** Error messages revealing filesystem structure or sensitive paths[1].
+- **Denial of Service:** Recursive or excessive resolution exhausting filesystem handles or causing application crashes[1].
+- **Path Traversal:** Malicious input allowing access to files outside the intended directory[4].
+
+### 6. Mitigation/Countermeasures
+
+| Threat Identified                          | Proposed Mitigation |
+|--------------------------------------------|---------------------|
+| Spoofing (malicious module IDs/config)     | Sanitize input IDs; validate against known patterns; restrict `basedir` to app-controlled paths[1][4]. |
+| Tampering (path traversal, cache)          | Validate input IDs for directory escapes; secure cache reads/writes; restrict cache to trusted sources[1][4]. |
+| Information Disclosure (error messages)    | Generic "not found" errors without internal paths; avoid exposing sensitive configuration in errors[1]. |
+| Denial of Service (resource exhaustion)    | Limit recursive resolution depth; implement timeout; monitor for excessive filesystem operations[1]. |
+
+### 7. Risk Ranking
+
+- **High:** Path traversal via malicious IDs (if not properly mitigated)
+- **Medium:** Cache tampering or spoofing (if cache is not secured)
+- **Low:** Information disclosure in errors (if error handling is generic)
+
+### 8. Next Steps & Review
+
+1. **Implement input sanitization for module IDs and configuration.**
+2. **Add resolution depth limiting and timeout.**
+3. **Audit cache handling for race conditions and tampering.**
+4. **Regularly review dependencies for vulnerabilities.**
+5. **Keep documentation and threat model up to date.**
+6. **Monitor for new threats as the ecosystem and library evolve[1][3].**