feat: update project name and licensing to KNEL-Football

- Update all project references from 'Secure Debian' to 'KNEL-Football'
- Add AGPLv3 license with copyright to Known Element Enterprises LLC
- Create comprehensive README.md with project overview and features
- Update copyright notices in all files
- Add project badges and documentation structure
- Maintain AGPLv3 only licensing throughout

PreFlightDiscussion-02.md

@@ -1,4 +1,4 @@
-# Pre-Flight Discussion - Round 2
+# KNEL-Football Pre-Flight Discussion - Round 2
 
 ## Follow-up Questions Based on Your Feedback:
 
@@ -6,51 +6,98 @@
 - **Your Feedback**: Entry point to tier0 infrastructure supporting ITAR/SECRET systems, CMMC Level 2/3 downstream, LI-SaaS for RackRental.net
 - **Questions**:
   - Should we target CMMC Level 3 for this system since it supports Level 2/3 downstream?
+  Yes
+
   - For STIG vs CIS: DISA STIGs are military requirements, CIS Benchmarks are industry best practices. Given your use case (tier0, ITAR/SECRET), I recommend DISA STIGs. Do you agree?
   - Should we implement the "Debian 13 STIG" or the more comprehensive "General Operating System STIG"?
 
+  How about we do both? Start with the CIS Benchmark for Debian Linux. Then layer on the Debian STIG.
+  It appears the last STIG was for Debian 11.
+
 ### 2. QR Code Import Implementation
 - **Your Feedback**: Want QR code import capability using webcam
 - **Questions**:
   - Which QR code library should we use? (qrencode for generation, zbar for scanning)
+
+Well we dont need to generate any qr codes do we? The system will only be a wireguard client. It won't have any systems connecting to it. 
+
   - Should we create a desktop shortcut for QR scanning, or integrate it into the WireGuard config management?
+
+How about a shell script to kick off the scan and update the config file?
+
   - What QR code format should we support? (Standard WireGuard QR format?)
 
+  I believe the standard wireguard qr format should be fine. I will test and we can tweak if it doesn't work.
+
 ### 3. Testing Strategy Clarification
 - **Your Feedback**: Test suite runs on installed system, not in build environment
 - **Questions**:
   - Should we include the test suite in the ISO itself for post-install validation?
+
+  Include in the ISO
+
   - Or keep tests separate for QA/validation before deployment?
   - How should the tests be triggered on the installed system? (Desktop shortcut, command line?)
 
+  command line.
+
+
 ### 4. Package Management Strategy
 - **Your Feedback**: Very minimal packages, re-image quarterly rather than update
 - **Questions**:
   - Should we remove apt/apt-get entirely to prevent accidental updates?
+
+  Yes
+
   - Or keep it but disable network access?
   - What's your preference for package management tools on the final system?
 
+  No package management tools on the final system allowed. At the very least they should have execute permission removed and be chattr +i . I don't know if Debian will let you remove things like apt and dpkg as they are pretty core to the system.
+
 ### 5. Preseed Configuration Details
 - **Your Feedback**: Only install target, root password, non-root user/password are manual
 - **Questions**:
   - What timezone should we default to?
+  US/Chicago
+
   - What keyboard layout should we default to?
+
+  Standard US English keyboard. 
+
   - Should we enforce password complexity in the preseed itself, or handle that post-install?
 
+  In the preseed itself
+
 ### 6. Secure Boot Implementation
 - **Your Feedback**: Must use secure boot, refuse to boot if altered
 - **Questions**:
   - Should we include Secure Boot keys in the ISO or use standard Microsoft keys?
+
+  Include secure boot keys in the ISO
+
+
   - Do you want UEFI-only boot, or support Legacy BIOS as well?
+
+  UEFI only
+
   - Should we implement measured boot or just standard Secure Boot?
 
+  Measured boot
+
 ### 7. Documentation Approach
 - **Your Feedback**: No user guides in ISO
 - **Questions**:
   - Should we create minimal inline help for the desktop shortcuts?
+  No
+
   - Or assume users are trained and don't need any documentation?
+
+  They are trained and dont need documentation
+
   - Where should we store technical documentation? (Project repo only?)
 
+  Repo only
+
 ## Clarifications Received:
 
 ### ✅ Test Environment: Keep tests separate from build environment, use shellcheck/shellfmt only in build