Pin the lock generation and document it

Why: inode reuse let a rebuilt lock pass Bind. The pin and the spec now require a shared lock_gen.
Evidence: Backend ef66bfb. SELF go test of instanceguard, store, and app.
Impact: Dev gitlink moves to ef66bfb. Operators still adopt only after confirming the same instance.
Refs: Backend pull request 183
Co-authored-by: Cursor <cursoragent@cursor.com>

docs/recovery/u8-sqlite-instance-guard.md

@@ -24,8 +24,8 @@ svc 的 `runtime/<name>/.start.lock` 只串行化脚本生命周期，挡不住
 
 两处记录，各管一种替换：
 
-1. 锁文件内容（持有 fd 时读写）：`v1 db_dev db_ino instance_id`。数据库 inode 与记录不一致，或记录还在而数据库文件消失，视为数据库被替换，**打开之前**拒绝。
-2. 表 `instance_guard`（迁移 v28，单行）：记录锁文件的 device/inode 与 instance_id。守卫建立之后，锁文件 inode 与表不一致，视为锁根丢失或锁文件被重建，打开并迁移之后拒绝，且不改写表。
+1. 锁文件内容（持有 fd 时读写）：`v1 db_dev db_ino instance_id lock_gen`。`lock_gen` 是 16 字节随机值的十六进制。数据库 inode 与记录不一致，或记录还在而数据库文件消失，视为数据库被替换，**打开之前**拒绝。
+2. 表 `instance_guard`（迁移 v28，单行）：记录锁文件的 device/inode、instance_id 与 `lock_gen`。守卫建立之后，锁文件 inode 与表不一致，或表里已有 `lock_gen` 而锁文件记录缺失/不一致，视为锁根丢失或锁文件被重建（含 inode 被回收后内容丢失），打开并迁移之后拒绝，且不改写表。
 
 尚无锁文件记录、表中也无行：视为首次建立（含旧库升级），写入两边。这是升级路径，不是 adopt。