#3822 swamp update downloads before failing in a sticky directory with another user's binary, and blames an immutable flag

Description

Since swamp-club#3817 (swamp-club/swamp#3325), the swamp update pre-flight checks that it can create a file in the binary's directory, instead of opening the binary for write. In a sticky directory (mode 1777, e.g. a /tmp-style directory) whose swamp binary belongs to another user, that check passes. A non-root user can create and remove their own probe file there.

The rename over the other user's binary then fails with EPERM. This happens only after the full download and checksum. The error says the binary is "protected against replacement" and points at an immutable flag (chflags or chattr), but the real cause is the sticky bit plus file ownership.

Before #3325 this case failed before the download with "Re-run with: sudo swamp update", which works here because root may rename in a sticky directory. So the message in this case got worse. Found by the CI adversarial review on #3325.

Steps to reproduce

1. As user A, put a swamp binary in a directory with mode 1777.
2. As user B (not root), run swamp update from that binary.
3. The download runs, then the update fails with the immutable-flag hint.

Expected

• The pre-flight refuses before downloading when the directory has the sticky bit, the binary belongs to another user, and the caller is not root.
• The hint names the sticky directory and suggests sudo swamp update, or taking ownership of the binary.
• The protected-binary message (dirWritable branch of permissionDeniedMessage in src/domain/update/update_service.ts) mentions sticky directories alongside immutable flags.

Notes

Rare setup: swamp is almost never installed into a world-writable sticky directory. Unit-testable via permissionDeniedMessage facts, plus a pre-flight test that stats the directory mode and the binary owner.