Make PRESENCE_CHECK_TIMEOUT configurable via env var

[DudeRandom21]

Summary

• Add SHIPIT_PRESENCE_CHECK_TIMEOUT environment variable to configure the presence check timeout (default: 30s)
• Deploy tasks were being reaped as dead during long bundle install steps (native extension compilation) where the hardcoded 30s timeout was too short
• Remove hardcoded PRESENCE_CHECK_TIMEOUT constant from Task in favor of Shipit.presence_check_timeout

Test plan

• Verify existing Task and ReapDeadTasksJob tests pass
• Confirm default (30) is preserved when env var is not set
• Confirm configured value is used when SHIPIT_PRESENCE_CHECK_TIMEOUT is set

🤖 Generated with Claude Code

[edilsonacjr]

Only one concern, not a huge problem but something that we can easily safeguard against.

---

Review assisted by pair-review

[edilsonacjr]

🐛 Bug: If SHIPIT_PRESENCE_CHECK_TIMEOUT is set to a non-numeric string (e.g. 'abc'), String#to_i returns 0. If set to '0' or a negative number, the parsed value is also non-positive. This value is passed as the ex: parameter to Shipit.redis.set(status_key, 'alive', ex: Shipit.presence_check_timeout) in Task#ping (task.rb:329). Redis requires the EX argument to be a strictly positive integer — a value of 0 or less raises Redis::CommandError: ERR invalid expire time in 'set' command. This would silently break liveness pings for all running tasks, causing ReapDeadTasksJob to reap them as dead — a worse outcome than the long-timeout problem this PR aims to solve.

Suggestion: Add a lower bound to ensure the timeout is always a positive integer:

Suggested change

	ENV.fetch('SHIPIT_PRESENCE_CHECK_TIMEOUT', 30).to_i
	[ENV.fetch('SHIPIT_PRESENCE_CHECK_TIMEOUT', 30).to_i, 1].max

Alternatively, you could raise a clear error at boot time if the value is invalid, rather than silently clamping.