fix: apply kukeon socket ownership in kuke daemon recreate

[eminwux]

Summary

kuke daemon recreate left /run/kukeon/kukeond.sock as 0600 root:root, so a non-root member of the kukeon group had to sudo to reach the daemon after a recreate — unlike kuke init, which leaves it 0660 root:kukeon. Reproduced on an upgrade-recreate (v0.7.1 daemon → v0.9.0 binaries → kuke daemon recreate).

Root cause — recreate skipped both things kuke init does to make the socket group-accessible:

1. Provision with the wrong GID. resolveProvisionKukeondCell hardcoded KukeondSocketGID: 0 (recreate.go). With GID 0, bootstrap.go:472's if socketGID > 0 gate omits --socket-gid from the kukeond cell's persisted args, so kukeond serve defaults to socketModeRootOnly (0o600) and never chowns to the group. kuke init passes ensure.GID (init.go:562).
2. No host-side re-assert. recreate never ran the post-ready sysuser.ChownAndChmod(socket, 0, gid, 0o660) that init.go:604 runs after the daemon binds the listener. This is the authoritative correction (the daemon resets ownership on every start).

Fix

• recreate.go: resolve the kukeon GID (via new lifecycle.LookupKukeonGID) and pass it as KukeondSocketGID; add a post-ready resolveApplySocketOwnership step (test-seamed via MockApplySocketOwnershipKey) that re-asserts root:kukeon 0o660, mirroring init. Prints a kukeond socket …: chown root:kukeon mode 0660 notice.
• consts.go: new KukeonSocketMode = 0o660 as the single source of truth; init.go's local kukeonSocketMode now references it so init and recreate can't drift again (this drift is the bug).
• lifecycle/socketdir.go: extract the existing inline kukeon-GID lookup into an exported LookupKukeonGID reused by both the run-dir ownership step and recreate.

Scope note (verified)

kuke daemon start/restart are not affected: they re-launch the existing kukeond cell via StartCell, whose persisted container args already carry --socket-gid (baked in at bootstrap.go:472 during the original init), so the daemon re-binds 0660 and chowns to the group itself. Only recreate re-provisions the cell from scratch and was dropping the GID. No host-side re-chown was added to start/restart.

Test plan

• make test (full CI suite, GOWORK=off) — exit 0
• GOWORK=off go build ./... — exit 0 (note: a bare go build ./... fails on a pre-existing third-party containerd/cgroups/v2 break; go.work documents that builds/tests must run GOWORK=off, which make and CI do)
• GOWORK=off go vet on touched packages — exit 0
• New unit tests: TestDaemonRecreate_AppliesSocketOwnership (ownership step invoked + chown notice printed) and TestDaemonRecreate_SocketOwnershipFailureIsWrapped (error propagation)
• End-to-end kuke daemon recreate on a real host verifying stat -c '%U:%G %a' /run/kukeon/kukeond.sock → root:kukeon 660 — not run; the dev host has no initialized kukeon runtime to recreate. Recommend the reviewer confirm on a clean host.

[eminwux]

PR #1341 Review — fix: apply kukeon socket ownership in kuke daemon recreate

LGTM — kuke daemon recreate now mirrors kuke init's socket-ownership path exactly: it resolves the kukeon GID and threads it into KukeondSocketGID (so bootstrap.go's if socketGID > 0 gate emits --socket-gid), then re-asserts root:kukeon 0o660 post-ready via resolveApplySocketOwnership — both halves the recreate path was previously dropping. The new consts.KukeonSocketMode collapses the init/recreate mode into one source of truth (the drift that caused the bug), and LookupKukeonGID is a clean extraction reused by both call sites with no duplicate inline lookups left behind. Errors wrapped with %w, no leaks, two new unit tests cover the ownership step + error propagation, CI all green.

Non-blocking, for you to run pre-merge: the one unchecked test-plan item is the documented host-gated e2e — kuke daemon recreate on a real initialized host, then stat -c '%U:%G %a' /run/kukeon/kukeond.sock → root:kukeon 660. The author flagged the dev host can't run it; the unit tests prove the wiring but not the on-host chown.