tenseleyflow/shithub / 9dab000

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.