RedBear-OS

Files

T

vasilito 9275126b37 phase 1.1: refresh gitlinks for 6 forks after Phase 0+1 work

After Phase 0 (Cargo.lock regen, version sync, fork verification) and
Phase 1.0A (orphan patch absorption commits), each affected fork
had new commits that the parent RedBear-OS index did not know
about. This caused persistent 'M local/sources/<fork>' entries in
'git status' (the M marker for submodule state divergence).

This commit refreshes the parent's gitlinks to each fork HEAD via
'git add <submodule-path>', which is the canonical way to record a
submodule update in the parent index.

Updated fork gitlinks (before -> after):
  base:         75f6cf90  -> 00b799d5  (Phase 1.0A patch recovery)
  bootloader:   9a12ee2e  -> 2f79630b  (Phase 0 Cargo.lock + version sync)
  installer:    04f80ba3  -> 8294ecbb  (Phase 0 Cargo.lock regen)
  kernel:       19b936ef  -> 0f3840a5  (Phase 1.0A patch recovery)
  relibc:       d60ba873  -> fa54b985  (Phase 1.0A patch recovery)
  userutils:    2bc1b8d5  -> 0dc0cb7   (Phase 0 Cargo.lock + version sync)

Unchanged (gitlink already matches HEAD):
  libredox:     6908adc9
  redoxfs:      b78a791e
  syscall:      6e4e5bdb

Per AGENTS.md 'BRANCH AND SUBMODULE POLICY' this commit is purely a
gitlink refresh after fork-side commits — it adds no new branches,
no new submodules, and makes no policy decisions.