Fix CE access guard not synced on push

Found by Task 10843's live proof on a ce-staging install (v1.2.5065, container node, one Operator-org user). What happened: project 1 (jaah-ai/jaah-ce-staging) had push_enabled=false (set in the console right after creation; confirmed by GET /api/projects/1). A coder runner then ran `git push --force-with-lease origin fleet/task-7` and the push LANDED on GitHub (branch fleet/task-7 appeared; since deleted). Only `jaah-forge pr create` refused ("this project has push_enabled=false"). The clone `/home/jaah/.jaah/repos/1/main/.git` had no `access-guard.*` markers, no `hooks/` dir and no disabled origin pushurl, i.e. neither layer of docs/policies/repo-access-levels.md § The git-native guard was present. Evidence: the CE `command_audit_log` holds no `sync_access_guard` row although `activity_events` records the `project_updated` with `push_enabled` in its fields at 14:37:49Z. Probable cause (verify): in `apps/api/app/routes/projects.py` (the guard-sync block after commit), `default_dispatch_node` for the CE's Operator principal falls through to `cp_node_id(...)` / `resolve_node_id() or "local"`, no `Node` row matches, so `resolve_clone(None, ...)` is empty and the sync is skipped silently. Separately, a fresh anchor clone gets markers only from that sync-on-change, so a project created with push off may never be guarded either. Ask: on the CE, every project clone carries the access guard matching its row (push_enabled, branch_prefix) from first clone onward, and a push_enabled change re-syncs it; a skipped sync is logged, never silent. Out of scope: cloud dispatch changes beyond what the fix needs; CE caps; doctrine prose. Done means: - On a CE install, a project with push_enabled=false: `git push origin HEAD:refs/heads/fleet/task-N` from its slot is refused by the pre-push hook (observed), and the clone's git config shows the access-guard markers. - Flipping push_enabled on an existing CE project writes a `sync_access_guard` row to command_audit_log and updates the markers. - A regression test covers the node resolution for the CE operator principal.

Already shipped in PR #7235 (2eb314ce9 + e389dce61): CE dispatch now resolves the edition's node, skipped syncs log a warning, and new clones are guarded from the project row. Checked by tests (72 jaahd + 51 API passed) and a refused push; no PR opened.