git hook lock records the parent shell PID ($$), so the #159 cap never holds #7

Problem

In ( ... ) &, $$ (git_hooks.py ~76) is the parent shell PID, which exits immediately; the lock is then judged stale and taken over, so the concurrency cap from elara-labs#159/elara-labs#160 is ineffective.

Impact in the AAP deployment

Git sh repro: 'pid 295 DEAD while subshell still running' (real subshell 296). Our installed hooks are the older guarded form, but any cce init would install this one.

Fix idea

Write the PID of the subshell / cce index process ($BASHPID, or sh -c 'echo $PPID').

Acceptance criteria

• A test runs the generated hook snippet and checks the recorded PID is alive while indexing runs. Fails without the change.
• tests/memory, tests/integration and tests/test_cli_serve.py show no new failure (3 test_memory_loop.py tests fail without a local embedding backend: baseline).
• ruff check clean on changed files.

Scope (Fabrics Codes item CCE-S6)

• src/context_engine/indexer/git_hooks.py
• tests/indexer/test_git_hook_lock_pid.py

Depends on items: none. Base: this fork's main (0.4.26+aap.x). Line numbers refer to main@0ef79c3.

Found by the CCE audit of 2026-10-11 (reproduced, not yet reported upstream).