fix(android): #115 root cause — drop proot --link2symlink (fixes git, pnpm, all link() tools)

[mega123-art]

What

Fix the #112/#115 git object-loss bug at its root: write a system /etc/gitconfig into the guest with core.createObject = rename, so git stops using the link() syscall that proot silently breaks.

One line of effect (Installer.kt):

writeFresh(File(p.rootfs, "etc/gitconfig"), "[core]\n\tcreateObject = rename\n")

Why

Under the untrusted_app SELinux domain (targetSdk 35, required for Play), proot's link() is a false success — it returns 0 but the target file never appears. git's default loose-object finalize path (git 2.43 object-file.c) is mkstemp → fsync → link(tmp,final) → unlink(tmp); git trusts the 0 from link, reports the object written, and the object is silently lost. This surfaces as fatal: remote did not send all necessary objects / bad object on git clone, and would hit commit/fetch/pull the same way.

core.createObject=rename sets OBJECT_CREATION_USES_RENAMES, which makes git skip link() entirely and use rename() — which proot handles correctly.

Proof (on-device, headless, untrusted_app — SM-A356E / Android 16)

Root cause caught at the syscall (probe9):

link ret=0 errno=0 target_exists_after=0   tmp_obj_mvrgkg -> objects/f0/6b470c...
hash-object exit=0        # git thinks it worked
count=0                   # nothing on disk

Fix proven (probe10):

link mode  (default):            50 written, survivors_on_disk=0    ← bug reproduced
rename mode (core.createObject):  50 written, survivors_on_disk=50   ← fixed

Verified through the shipping path (system /etc/gitconfig, plain git clone, no per-command flag):

git config --show-origin core.createObject  ->  file:/etc/gitconfig  rename
git clone https://github.com/expressjs/express.git  ->  exit 0, done.
HEAD=ae6dd376   in-pack: 53322   packs: 1   checkout: OK   worktree files: 213   fsck errors: 0

Relation to other work

• Supersedes Fix #112: git clone in the proot guest under targetSdk-35 #114 (the dulwich clone shim, merged 509dee6): that fixed clone only, by swapping real git for pure-Python dulwich (which writes objects with create+rename, dodging link). This PR fixes all git commands with real git and one config line. Once merged, Run the engine natively (no proot in the hot path): structural fix for the untrusted_app transport corruption #115 T3 (remove the dulwich shim) can proceed.
• Root-cause hunt: builds directly on @zo-sol's handoff in Run the engine natively (no proot in the hot path): structural fix for the untrusted_app transport corruption #115 (proven eliminations: network, socket recv, rseq, l2s, rename; narrowed to git's loose-object write). Full evidence: #115 comment and the confirmation #115 comment.
• Original context: git clone always fails in proot (Android) guest — "remote did not send all necessary objects" (suspected Ubuntu 24.04 rseq regression) #112 (root cause + verification threads), Run the engine natively (no proot in the hot path): structural fix for the untrusted_app transport corruption #115 (structural-fix issue).
• Not this PR (still open): the basement fix — patching proot's linkat translation so link() stops lying for every tool (npm/cargo/…), in our own proot build (we own it from the Seeker process_vm fix; GPLv2 → publish the patch). core.createObject=rename fixes git, the only proven-affected tool today; the proot patch stays tracked in Run the engine natively (no proot in the hot path): structural fix for the untrusted_app transport corruption #115.

Also in this branch (debug kit, not shipped code)

• debug/issue-115/probes/probe10.sh — the fix test (reproduce in link mode → prove in rename mode → real clone).
• debug/issue-115/shims/liblinkfix.c — a broader LD_PRELOAD option (returns EXDEV on object-path link/linkat, forcing the caller's own rename fallback) for any non-git tool that hits the same false-success and has no config knob.
• debug/issue-115/README.md — the fix ladder (config → shim → proot patch).

Headless reproduction used for all the evidence above lives on feat/115-native-exec-probe (NativeProbeActivity guest-script mode: am start … -e guestScript /root/probeN.sh runs a probe through proot from the app process, so git inherits untrusted_app — same domain as the in-app chat, drivable over pure adb, no agent auth). Kept separate from this shippable fix.

Test plan

1. Fresh install (or clear app data so the installer re-runs configureGuest).
2. In-app: git clone https://github.com/expressjs/express.git → completes, git fsck clean.
3. Confirm the config is live: guest git config --show-origin core.createObject → file:/etc/gitconfig rename.

[mega123-art]

Update: found the real root cause — it's --link2symlink, and the fix is to remove it

The core.createObject=rename gitconfig (first commits) fixes git, but git isn't the only victim. Dug to the actual root cause; it's one flag, and removing it fixes every tool at once.

Root cause (proven on-device, SM-A356E, untrusted_app)

In the untrusted_app domain the kernel denies hardlinks: ln a b → Permission denied, links=1. We launch proot with --link2symlink, whose extension catches that denial and fakes success — it pokes the syscall result to 0 and swaps in a symlink-refcount scheme (moving the file into PROOT_L2S_DIR, replacing the target with a symlink). That fake defeats callers' own error handling:

• git finalize_object_file falls back to rename only when link fails — never when it returns a lying 0.
• pnpm's store-linker falls back to copy only when the hardlink fails — never when it lies.

So both get a 0, skip their fallback, and the symlink dangles → silent git object loss and broken pnpm installs. This is exactly probe9's link ret=0 target_exists_after=0.

The fix: drop --link2symlink

Then linkat fails honestly with EACCES and every tool with a fallback recovers itself. Verified on-device with l2s off:

ln a b:                     Permission denied  (honest — no more fake success)
git (forced link mode):     50/50 loose objects survive   (rename fallback)
pnpm (default hardlink):    589/589 files, require OK      (copy fallback)
node server boot:           server ready (HTTP 200)        (no regression)

One flag removed fixes git + pnpm + any link()-using tool — no proot rebuild, no per-tool config. This is the "fix the basement" answer: the defect was proot faking a syscall, and we stop it faking.

What this PR now contains

1. DirectProotExec: remove --link2symlink — the root-cause fix, all tools.
2. Installer: core.createObject=rename system gitconfig — kept as belt-and-suspenders for git (skips the doomed link attempt entirely), and written on every launch so existing installs get it without a rootfs re-extract.

Supersedes the clone-only dulwich shim (#114) — real git, all commands, plus pnpm and the rest. #115 T3 (remove the dulwich shim) can proceed.

Note on the earlier "l2s isn't it" elimination

The handoff eliminated --link2symlink because ln showed links=2 (a real hardlink). That test was in runas_app, where hardlinks are allowed — so l2s passed the real link through untouched and looked innocent. The bug only appears in untrusted_app, where the real link is denied and l2s's fake-success path activates. Same reason the whole bug is domain-specific.