Adds the actions block to sqlc.yaml + the per-table .sql query files.
sqlc generate produces internal/actions/sqlc/ with one .sql.go file
per query file plus models.go (the Go structs mirroring the schema)
and querier.go (the Queries interface).
Just enough surface for S41b/c/d to read and write the rows. No
orchestration logic in this commit; the workflow package (next two
commits) layers on top.
Pre-fix: shithubd-web's systemd unit set RestrictSUIDSGID=yes.
SR2 #287 made InitBare run 'git init --bare --shared=group' so
cross-user write paths (HTTPS path as user shithub, SSH path as
user git, both in shithub group) inherit shithub group on new
pack files. git's adjust_shared_perm calls chmod g+s on every
directory it creates. The kernel returned EPERM under the
restriction; git emitted:
fatal: Could not make .../branches/ writable by group
so every fresh repo create on a new owner namespace failed with
the bland 'Could not create the repository' UI error after the
PR #48 deploy. Existing repos (created before #48) had been
post-init-repaired by 'shithubd storage repair-shared-perms'
running as root, so their setgid was already in place.
Fix: drop the directive. shithubd doesn't write executable files
to disk and isn't a setuid host, so the security loss is small.
The other hardening (NoNewPrivileges, ProtectSystem=strict,
ProtectHome, MemoryDenyWriteExecute, RestrictNamespaces, etc.)
all stay.
Alternative considered + rejected: keep RestrictSUIDSGID, drop
--shared=group, and chmod perms by hand post-init. That re-
introduces the SR2 #287 bug pattern (custom perms recipe drifts
from git's expected layout, future operators hit subtle perm bugs).
Operator must reload the unit on existing droplets:
ssh root@shithub.sh 'systemctl daemon-reload && systemctl restart shithubd-web'
This was already applied to the live droplet at fix-time.
Pre-fix: friendlyCreateError collapses every non-typed cause into
'Could not create the repository. Try again.' for the user. The
handler swallowed the original err entirely, so the operator had
no signal in journalctl when a create failed for a reason outside
the typed-sentinel set.
User reports a repeatable failure creating a repo under a brand-
new org with no log line to triage. Add a WarnContext with the
error + push-event metadata so the next failure surfaces what
actually went wrong.
Cheap, no behavior change for the user, immediately useful when
diagnosing the next failed create.
