Cap health check backoff and add Lambda deadline guard

[pcholakov]

Summary

Closes #91. ServiceDeployer's exponential-backoff health check could run for ~35 minutes when the Restate admin endpoint was unreachable - well past Lambda's 15-minute hard limit. The Lambda would be killed mid-sleep without sending a CloudFormation response, leaving CFN to wait its 60-minute step timeout before failing the stack.

The schedule is 2 ** attempt * 1_000 ms plus 0-2 s jitter, capped only by MAX_HEALTH_CHECK_ATTEMPTS = 10 (which was bumped from 5 in 1.5.0). The last two sleeps alone were ~8.5 min and ~17 min.

Changes

• Cap each iteration's backoff at 20 s so the worst-case loop stays under the 5-minute default Lambda timeout (~216 s vs 300 s budget) without changing the deployer Lambda's timeout or anyone's CFN template.
• Add a deadline guard using context.getRemainingTimeInMillis() that aborts the loop with a clear error if the remaining budget can't cover the next request plus 60 s reserved for the registration loop, optional pruning, and the CFN response submission.
• Expose healthCheckRetryAttempts and healthCheckMaxBackoff on ServiceRegistrationProps for users who need to tune the loop. Defaults are emitted only when the caller sets them explicitly, so existing CFN templates see no property diff.

Test plan

• npm run build clean
• npm run test all 11 pass (1 snapshot updated for the registration handler asset hash, expected since the Lambda code changed)
• New tests verify the new props are forwarded when set and absent when unset
• Existing snapshots unchanged (template stability)
• Manual: deploy with an unreachable adminUrl and verify the deployer Lambda errors inside its own timeout instead of CFN sitting at the resource for 60 minutes

Notes

The registration loop (MAX_REGISTRATION_ATTEMPTS = 3, max ~56 s of sleeps) is unchanged - it's already short and the new 60 s reserve in the deadline guard accounts for it.