Upgrade the umask fix to match upstream PR #9/#12

[sandamond]

Summary

Our earlier umask fix (merged in #2) worked but is weaker than the fixes independently proposed upstream in telegramdesktop/tproxy-server#9 and #12 for telegramdesktop/tproxy-server#10. Adopting their approach here:

• MTProxy permissions: the fix only ran inside install-mtproxy.sh's "rebuild from source" branch. A host where a previous run left /opt/MTProxy built with bad permissions would keep skipping the (already-present, pinned-commit) build on every later run and never reach the fix. Moved after the build-or-skip block so it runs on every invocation. Also narrowed from chmod -R a+rX (every user on the host) to chown root:mtproxy + chmod 0750 on exactly objs, objs/bin, and the binary — matching the root:mtproxy 0750 scheme this installer already uses for /etc/mtproxy. Confirmed on the deployed host that the mtproxy service user's primary group actually is mtproxy before relying on that.
• go test: the fix wrapped the call site in install.sh ((umask 022; ...)), which only helps there — go test ./... run directly, outside install.sh, under a restrictive shell umask would still fail the same way. Fixed at the source instead: TestLoadAcceptsSystemdCredentialReadPermissions now chmods its own fixture explicitly after writing it. The now-unnecessary install.sh wrapper is reverted.

Test plan

• go test ./... passes under umask 077 with no wrapper at the call site (re-verified on a real host, this exact tree)
• gofmt -l . and go vet ./... clean
• Confirmed id mtproxy → primary group mtproxy on the deployed host, so the narrower chown root:mtproxy grants exactly what the service needs
• Not re-run against the live deployed host in this PR — it already has correct (broader) permissions from the previous fix and three real client keys in active use; re-running the full installer resets its profiles.json, which isn't something to do incidentally while verifying a permissions tweak

🤖 Generated with Claude Code