Fix two umask-dependent failures in a fresh installation

[naprelsky]

deploy/install.sh sets umask 077 on its first line. Two later steps rely on
default permissions and break under it, so a fresh installation on a clean
Ubuntu 24.04 host fails twice before the relay ever serves a request. Both
failures look like a broken environment rather than a permission default, which
is what cost me the time to track them down.

1. The test suite aborts the install

install.sh runs go test ./... before building. Under umask 077,
TestLoadAcceptsSystemdCredentialReadPermissions writes its profiles file with
os.WriteFile(..., 0444), the umask clears the group and other bits, and the
file lands as 0400. The negative half of the test — a group-readable profiles
file outside a credential directory must be rejected — then has nothing to
reject, Load succeeds, and the test fails on its own assertion:

--- FAIL: TestLoadAcceptsSystemdCredentialReadPermissions (0.00s)
    config_test.go:248: group/other-readable profiles file outside a credential directory was accepted

The permission check in loadProfiles is correct; only the test is
umask-dependent. Fixed by chmod'ing the file after writing it.

2. MTProxy cannot start, so the relay never becomes ready

make in install-mtproxy.sh also runs under umask 077, creating objs/,
objs/bin/ and mtproto-proxy as 0700. The chown -R root:root that follows
leaves them owned by root with no group access, while mtproxy.service runs as
User=mtproxy:

mtproxy.service: Main process exited, code=exited, status=203/EXEC
mtproxy.service: Start request repeated too quickly.

The relay itself starts fine but stays at /readyz 503 backend unavailable,
and install.sh ends with tproxy-server did not become ready.

Fixed with root:mtproxy 0750 on the two directories and the binary, reusing
the scheme the installer already applies to /etc/mtproxy. The commands run on
every invocation rather than only after a rebuild: the rebuild guard tests -x
as root, which passes on a 0700 binary, so an already affected host cannot be
repaired by re-running the installer otherwise.

A single-line alternative for the second issue would be to build under a
permissive umask, but that also relaxes everything else make writes, so
granting the runtime group exactly what it needs seemed closer to the intent of
the surrounding code. Happy to switch if you prefer the other shape.

Verification

On a fresh clone at 52a5feb, Ubuntu 24.04, Go 1.22:

• before the patch, umask 077; go test -count=1 ./internal/config/ fails as above;
• after the patch, umask 077; go test -count=1 ./... and umask 022; go test -count=1 ./... both pass;
• bash -n deploy/install-mtproxy.sh is clean;
• a full deploy/install.sh --hostname … --site-upstream … run completes, mtproxy stays active, /healthz and /readyz return 200, and / and /?bridge=<invalid> return the operator site byte for byte.

🤖 Generated with Claude Code