Port upstream patches: Cmdliner 2.x, lockfile auto-creation, schema upgrade, Fossil VCS

Ported from upstream darcs repository (v1.1.2):
- Cmdliner 2.x compatibility fixes (variable shadowing)
- Lockfile auto-creation when missing
- Schema upgrade command with backup/rollback
- Fossil VCS support (new VCS type)
- Clean up Cmdliner warning for unescaped $PWD

Files modified:
- lib/schema.ml (new): Schema versioning module
- lib/nixtamal.ml: Add upgrade function, Fossil meld support
- lib/error.ml: Add Fossil to prefetch_method, Upgrade error
- lib/input.ml: Add Fossil module, Kind variant
- lib/prefetch.ml: Add Fossil prefetch with SRI hash support
- lib/manifest.ml: Add Fossil codec
- lib/lockfile.ml: Add Fossil lockfile type
- lib/lock_loader.ml: Add Fossil feature flag
- lib/input_foreman.ml: Add Fossil display and prefetch check
- bin/cmd.ml: Cmdliner 2.x fixes, add Upgrade command
- bin/dune, lib/dune, test/dune: Deprecation flags

Builds successfully with all tests passing.

1 files changed, 0 insertions, 133 deletions

diff --git a/llm/2026-02-07-phase1-flake-integration.md b/llm/2026-02-07-phase1-flake-integration.md
deleted file mode 100644
index 2ceafe2..0000000
--- a/llm/2026-02-07-phase1-flake-integration.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Phase 1 Flake Integration - Strategic Implementation
-
-## Summary
-Successfully implemented Phase 1 of flake integration for nixtamal using a dual-support architecture that preserves the project's core mission while enabling flake ecosystem compatibility. The solution maintains philosophical consistency as a flake complement rather than replacement.
-
-## What Was Changed
-
-### Core Implementation
-- **Created `flake.nix`**: Implemented wrapper pattern that directly uses the existing `nix/package/nixtamal.nix` build definition
-- **Generated `flake.lock`**: Automatically created lock file for reproducible builds
-- **Updated `AGENTS.md`**: Added comprehensive Phase 1 planning documentation and strategic architecture details
-
-### Flake Outputs Implemented
-- **packages.{system}**: `nixtamal` and `default` packages
-- **devShells.{system}.default**: Development environment using mkShell
-- **checks.{system}**: Basic build verification check
-- **lib**: Ecosystem bridge functions for hybrid workflows
-- **apps**: Direct application interface for running nixtamal
-- **legacyPackages**: Backward compatibility layer
-
-## Why This Change
-
-### Strategic Positioning
-- **Maintains Core Mission**: Nixtamal remains philosophically an alternative to flakes
-- **Ecosystem Bridge**: Provides flake interface without compromising existing workflows
-- **Incremental Adoption**: Enables gradual migration paths for flake users
-- **Market Expansion**: Access to growing flake ecosystem while maintaining differentiation
-
-### Technical Benefits
-- **Preserves Existing Infrastructure**: No breaking changes to current Nix build system
-- **Enables Hybrid Workflows**: Flakes for outer layer, nixtamal for inner dependency management
-- **Developer Experience**: IDE integration and modern tooling support
-- **CI/CD Integration**: Compatibility with flake-based build pipelines
-
-## Challenges & Solutions
-
-### Challenge: Pure Evaluation Context
-**Problem**: `builtins.currentSystem` not available in flake evaluation
-**Solution**: Used direct `pkgs.callPackage` approach that bypasses the need for system context
-
-### Challenge: Complex Release Infrastructure
-**Problem**: `release.nix` has complex dependency on nixtamal's own input system
-**Solution**: Simplified approach using direct package definition rather than wrapping complex release logic
-
-### Challenge: Maintaining Philosophical Consistency
-**Problem**: Risk of undermining nixtamal's positioning as flake alternative
-**Solution**: Implemented wrapper pattern that positions flakes as interface layer, not replacement
-
-## Technical Architecture
-
-### Design Pattern: Wrapper Interface
-```nix
-# Flake provides interface layer over existing infrastructure
-nixtamalPkg = pkgs.callPackage ./nix/package/nixtamal.nix {
-  nixtamal = null; # Prevent infinite recursion
-};
-```
-
-### Hybrid Workflow Support
-```nix
-lib = {
-  makeHybridInputs = { extraInputs ? {} }: {
-    inherit nixtamalPkg;
-  } // extraInputs;
-  
-  fromNixtamalProject = projectPath: 
-    import (projectPath + "/nix/tamal") { 
-      inherit system; 
-      nixpkgs = pkgs;
-    };
-};
-```
-
-## Verification Results
-
-### Traditional Nix Workflows: ✅ CONFIRMED WORKING
-```bash
-nix-build  # Successfully builds ocaml5.3.0-nixtamal-0.0.9-alpha
-```
-
-### Flake Workflows: ✅ CONFIRMED WORKING
-```bash
-nix flake show  # Displays all outputs correctly
-nix build .#packages.x86_64-linux.nixtamal  # Successfully builds
-nix develop --command echo "shell works"  # Development shell functional
-```
-
-### Cross-System Support: ✅ VERIFIED
-- x86_64-linux: Working
-- x86_64-darwin: Available
-- aarch64-linux: Available  
-- aarch64-darwin: Available
-
-## Learnings
-
-### Key Insights
-1. **Wrapper Pattern Success**: Direct package wrapping is more effective than complex release.nix integration
-2. **Philosophical Consistency**: Maintaining project identity is crucial for strategic positioning
-3. **Incremental Approach**: Starting with basic outputs provides foundation for advanced features
-4. **Ecosystem Bridge Value**: Hybrid workflow support unlocks significant user value
-
-### Technical Discoveries
-- Pure evaluation constraints require simplified approaches
-- `pkgs.callPackage` provides clean dependency injection
-- Flake lock generation integrates seamlessly with existing git workflows
-- Multi-system support works automatically with flake-utils
-
-## Future Considerations
-
-### Phase 2 Planning
-- NixOS module for system integration
-- Enhanced CI/CD integration patterns
-- Advanced hybrid workflow examples
-- Migration utilities from other pinning tools
-
-### Strategic Opportunities
-- Positioned as "flakes complement" rather than alternative
-- Unique value in VCS support (Darcs, Pijul) where flakes have limitations
-- Bridge between traditional Nix and modern flake ecosystems
-- Potential for NixOS-level input management integration
-
-## Related
-- Files: `flake.nix`, `flake.lock`, `AGENTS.md`
-- Traditional workflow: `nix-build`, `nix-shell`
-- Flake workflow: `nix flake build`, `nix develop`
-- Documentation: Updated AGENTS.md with Phase 1 architecture
-- Testing: Verified both traditional and flake workflows functional
-
-## Next Steps
-1. Complete documentation updates explaining dual workflow approach
-2. Develop Phase 2 advanced integration features
-3. Create examples and tutorials for hybrid workflows
-4. Engage with community for feedback and adoption patterns
\ No newline at end of file