fix(lock): prefer $EPOCHSECONDS over date +%s for stale lock time check

[kitsuyui]

Summary

On platforms where date +%s is unavailable (restricted environments,
minimal Docker images, some self-hosted runners), the time-based stale
lock detection in acquire_boilerplates_lock() silently degraded to a
no-op, leaving only the PID liveness check active.

This PR replaces:

now=$(date +%s 2>/dev/null) || now=0

with:

now=${EPOCHSECONDS:-$(date +%s 2>/dev/null || echo 0)}

$EPOCHSECONDS is a bash 5.0+ built-in variable that exposes the current
Unix epoch without spawning an external process. GitHub-hosted runners
(ubuntu, macos, windows) all provide bash 5.x through shell: bash.
On bash < 5 the variable is unset and the fallback to date +%s applies,
preserving existing behaviour.

Impact

• Normal conditions: no behavioural change (both sources return the same value)
• bash 5+, date +%s unavailable: time-based stale detection now works
• bash < 5, date +%s unavailable: unchanged (time-based check remains disabled)

Related

PR #54 addresses visibility of pid_ts write failure on the acquisition side.
That PR and this one are independent — the write-side timestamp format is unchanged.

Test plan

• CI passes on ubuntu-latest, macos-latest, windows-latest
• No change in existing stale-lock detection behaviour