feat: build system transition to release fork + archive hardening

Release fork infrastructure:
- REDBEAR_RELEASE=0.1.1 with offline enforcement (fetch/distclean/unfetch blocked)
- 195 BLAKE3-verified source archives in standard format
- Atomic provisioning via provision-release.sh (staging + .complete sentry)
- 5-phase improvement plan: restore format auto-detection, source tree
  validation (validate-source-trees.py), archive-map.json, REPO_BINARY fallback

Archive normalization:
- Removed 87 duplicate/unversioned archives from shared pool
- Regenerated all archives in consistent format with source/ + recipe.toml
- BLAKE3SUMS and manifest.json generated from stable tarball set

Patch management:
- verify-patches.sh: pre-sync dry-run report (OK/REVERSED/CONFLICT)
- 121 upstream-absorbed patches moved to absorbed/ directories
- 43 active patches verified clean against rebased sources
- Stress test: base updated to upstream HEAD, relibc reset and patched

Compilation fixes:
- relibc: Vec imports in redox-rt (proc.rs, lib.rs, sys.rs)
- relibc: unsafe from_raw_parts in mod.rs (2024 edition)
- fetch.rs: rev comparison handles short/full hash prefixes
- kibi recipe: corrected rev mismatch

New scripts: restore-sources.sh, provision-release.sh, verify-sources-archived.sh,
check-upstream-releases.sh, validate-source-trees.py, verify-patches.sh,
repair-archive-format.sh, generate-manifest.py

Documentation: AGENTS.md, README.md, local/AGENTS.md updated for release fork model

docs/06-BUILD-SYSTEM-SETUP.md

@@ -8,19 +8,18 @@
 
 ## Repository Model Reminder
 
-Build this repository using the Red Bear overlay model:
+Build this repository using the Red Bear release fork model:
 
-- upstream-owned source trees are refreshable working copies,
+- sources are frozen, immutable release snapshots at baseline 0.1.0,
 - durable Red Bear state lives in `local/patches/`, `local/recipes/`, `local/docs/`, and tracked
   Red Bear configs,
-- upstream WIP recipes are useful inputs, but should not automatically be treated as the durable
-  shipping source of truth for Red Bear.
+- build from archived sources offline by default; provision new releases explicitly via provision-release.sh.
 
 Resilience policy for package/source inputs:
 
 - default build posture is local-first/offline-capable,
-- local copies are used continuously unless upstream refresh is explicitly requested,
-- upstream refresh is an explicit operation, not an implicit background requirement for normal
+- local copies are used continuously unless release provisioning is explicitly requested,
+- release provisioning is an explicit operation, not an implicit background requirement for normal
   builds.
 
 ## Prerequisites
@@ -210,11 +209,11 @@ sudo dd if=build/x86_64/harddrive.img of=/dev/sdX bs=4M status=progress
 ./target/release/repo cook recipes/wip/kde/kwin
 ```
 
-Under the Red Bear overlay model, remember:
+Under the Red Bear release fork model, remember:
 
-- `recipes/*/source/` is a refreshable working tree,
+- `recipes/*/source/` is an immutable archived release snapshot,
 - Red Bear-owned shipping deltas should be preserved under `local/patches/` and `local/recipes/`,
-- if a recipe is still upstream WIP, Red Bear may still choose to ship from `local/recipes/` instead.
+- sources are built offline by default; provision new releases via provision-release.sh.
 
 ### Understanding Recipe Format
 
@@ -264,7 +263,7 @@ cp target/release/myapp ${COOKBOOK_STAGE}/usr/bin/
 | `PREFIX_BINARY` | `1` | Use prebuilt toolchain (faster) |
 | `REPO_BINARY` | `0` | Use prebuilt packages (faster, no compilation) |
 | `REPO_NONSTOP` | `0` | Continue on build errors |
-| `REPO_OFFLINE` | `0` | Don't update source repos; Red Bear policy treats local-first sourcing as the normal operating mode and upstream refresh as explicit opt-in |
+| `REPO_OFFLINE` | `0` | Don't update source repos; Red Bear policy treats local-first sourcing as the normal operating mode and release provisioning as explicit opt-in |
 
 ### Environment Variables for Recipes
 

docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md

@@ -17,26 +17,26 @@ Detailed subsystem planning remains in focused documents under `local/docs/`.
 
 ## Repository Model
 
-RedBearOS should be understood as an overlay distribution on top of Redox in the same way Ubuntu
+RedBearOS should be understood as an full fork on top of Redox in the same way Ubuntu
 relates to Debian.
 
 - Redox is upstream.
-- Red Bear carries integration, packaging, validation, and subsystem overlays on top.
-- Upstream-owned source trees are refreshable working copies.
+- Red Bear carries integration, packaging, validation, and subsystem release fork on top.
+- Upstream-owned source trees are immutable archived release snapshot.
 - Durable Red Bear state belongs in `local/patches/`, `local/recipes/`, `local/docs/`, and tracked
   Red Bear configs.
 
-The project is in the right long-term shape only when refreshed upstream sources can be fetched,
-Red Bear overlays can be reapplied, and the project still rebuilds successfully.
+The project is in the right long-term shape only when immutable archived upstream sources can be fetched,
+Red Bear release fork can be apply, and the project still rebuilds successfully.
 
 ## Ownership Rules
 
 ### Upstream-owned layer
 
-These are refreshable working inputs, not durable Red Bear storage:
+These are immutable archived release sources, not durable Red Bear storage:
 
 - `recipes/*/source/`
-- most of `recipes/` outside local overlay symlinks
+- most of `recipes/` outside local release fork symlinks
 - mainline configs such as `config/desktop.toml` and `config/minimal.toml`
 - generated build outputs under `target/`, `build/`, `repo/`, and recipe-local `target/*`
 
@@ -63,7 +63,7 @@ If an upstream recipe or subsystem is still marked WIP, Red Bear treats it as a
 That means:
 
 1. upstream WIP can be used as an input and reference,
-2. but Red Bear should fix and ship from the local overlay while the work is still WIP,
+2. but Red Bear should fix and ship from the local release fork while the work is still WIP,
 3. and once upstream promotes that work to first-class supported status, Red Bear should reevaluate
    and prefer upstream where appropriate.
 
@@ -80,7 +80,7 @@ That means:
 
 - functionality is delivered as packages,
 - profiles are composed from packages and package groups,
-- integration should prefer packaging, configuration, and overlays over invasive upstream rewrites.
+- integration should prefer packaging, configuration, and release fork over invasive upstream rewrites.
 
 ### Validation over claims
 
@@ -148,11 +148,11 @@ The current repo is no longer at a greenfield or “missing everything” stage.
 
 The current evidence-backed baseline is:
 
-- the Red Bear overlay model is documented and in active use,
+- the Red Bear release fork model is documented and in active use,
 - major local subsystem plans exist under `local/docs/`,
 - native wired networking is present,
 - Qt6 and major downstream desktop dependencies build,
-- Wayland-facing relibc compatibility surfaces now rebuild from a refreshed upstream relibc source
+- Wayland-facing relibc compatibility surfaces now rebuild from a immutable archived upstream relibc source
   tree via local patch carriers,
 - `libwayland` and `qtbase` build successfully from the reconstructed relibc state,
 - the Red Bear-native greeter/login path now has a bounded passing runtime proof, while broader KDE/KWin session stability is still not yet a general runtime claim,
@@ -170,7 +170,7 @@ ordering.
 
 The current repository-wide work order is:
 
-1. repository discipline and overlay hygiene
+1. repository discipline and release fork hygiene
 2. reproducible profiles and validation surfaces
 3. low-level controller and IRQ quality
 4. USB maturity
@@ -202,27 +202,27 @@ order.
 
 ## Workstreams
 
-### 1. Repository discipline and overlay hygiene
+### 1. Repository discipline and release fork hygiene
 
 Goal:
 
 - keep Red Bear-specific work identifiable,
-- keep upstream refresh predictable,
-- ensure durable overlays exist for active Red Bear-owned deltas,
+- keep release provisioning predictable,
+- ensure durable release fork exist for active Red Bear-owned deltas,
 - keep WIP migration logic explicit.
 
 Current state:
 
-- overlay model is documented,
-- relibc preservation/reapply proof exists,
+- release fork model is documented,
+- relibc preservation and patch application proof exists,
 - WIP ownership policy is documented,
 - documentation still needs cleaner indexing and some historical pruning.
 
 Acceptance:
 
-- refreshed upstream sources can be re-overlaid and rebuilt predictably,
+- sources are provisioned via provision-release.sh and rebuilt predictably,
 - the canonical/current-vs-historical split is visible in docs,
-- active Red Bear-owned deltas are preserved outside refreshable source trees.
+- active Red Bear-owned deltas are preserved in local/patches and local/recipes.
 
 ### 2. Profiles and packaging
 
@@ -435,9 +435,9 @@ Do not compress these into a single “supported” claim.
 The highest-value documentation follow-ups from the current state are:
 
 1. add a clearer document-status matrix in `docs/README.md`,
-2. add a WIP migration ledger for major upstream-WIP-to-local-overlay transitions,
+2. add a WIP migration ledger for major upstream-WIP-to-local-release fork transitions,
 3. add a concise script behavior matrix for sync/fetch/apply/build helper scripts,
-4. continue pruning obsolete local overlays only after refreshed-upstream reapply proofs confirm
+4. continue pruning obsolete local release fork only after release provisioning proofs confirm
    upstream coverage is sufficient.
 
 ## Bottom Line
@@ -445,11 +445,11 @@ The highest-value documentation follow-ups from the current state are:
 Red Bear OS is no longer at the stage where the main question is “can we start?”.
 
 The current state is a transition from compile-oriented subsystem accumulation toward a stricter,
-profile-driven, overlay-disciplined, evidence-backed system project. The implementation plan must now
+profile-driven, release fork-disciplined, evidence-backed system project. The implementation plan must now
 optimize for:
 
-- predictable upstream refresh,
-- durable local overlays,
+- predictable release provisioning,
+- durable local release fork,
 - honest support language,
 - and execution order that respects the real blocker chain.
 

docs/README.md

@@ -1,6 +1,6 @@
 # Red Bear OS Documentation Index
 
-Technical documentation for Red Bear OS as an overlay distribution on top of Redox OS.
+Technical documentation for Red Bear OS as an full fork on top of Redox OS.
 
 This index is the entry point for the documentation set. Its main job is to make the
 current/canonical versus historical/reference split obvious.
@@ -21,13 +21,13 @@ current/canonical versus historical/reference split obvious.
 
 > **Repository model:** RedBearOS relates to Redox in the same way Ubuntu relates to Debian.
 > Upstream Redox remains the base platform; Red Bear carries packaging, patch, validation, and
-> subsystem overlays on top. For long-term stability, upstream-owned source trees should be treated
-> as refreshable working copies, while durable Red Bear state belongs in `local/patches/`,
+> subsystem release fork on top. For long-term stability, upstream-owned source trees should be treated
+> as immutable archived release snapshot, while durable Red Bear state belongs in `local/patches/`,
 > `local/recipes/`, `local/docs/`, and tracked Red Bear configs.
 >
 > **WIP policy:** if an upstream recipe or subsystem is still marked WIP, Red Bear treats it as a
-> local project until upstream promotes it to first-class status. We may refresh from upstream WIP,
-> but we should fix and ship from the Red Bear overlay until upstream support is real enough to
+> local project until upstream promotes it to first-class status. We may immutable archived from upstream WIP,
+> but we should fix and ship from the Red Bear release fork until upstream support is real enough to
 > replace the local copy.
 
 ## Document Status Matrix