Fix crash when ext-session-lock-v1 is unavailable during startup

[B2krobbery]

Fixes #999

When hyprlock is launched immediately at compositor startup,
ext-session-lock-v1 may not yet be available.

Previously this was treated as a fatal error, causing hyprlock
to abort.

This change retries binding for a short period, allowing the
compositor to finish initialization before failing.

Note: This introduces a short blocking wait (with brief delays and additional
Wayland roundtrips) during startup, ensuring globals are processed and avoiding
premature aborts (maximum ~500 ms).

[PointerDilemma]

Uhm no? roundtrip is "Block until all pending request are processed by the server".
So when it finishes, the entire registry must be populated. Otherwise this is probably a compositor bug. Am I wrong @vaxerski?

[B2krobbery]

That makes sense, thanks for clarifying.

This behavior only happens when launching via
exec-once = hyprlock --immediate, where hyprlock seems to start
very early during compositor initialization. Running hyprlock a bit
later manually works fine.
Because of that, it looks like a startup timing issue in practice,
even though wl_display_roundtrip() should guarantee that the
registry is fully populated.
If this instead indicates a compositor-side issue, I’m happy to
look into that direction or adjust the approach.

[vaxerski]

probably a compositor bug but shouldn't happen, odd

[B2krobbery]

Got it, thanks.
In that case, this is mainly a safeguard against that startup condition
to avoid crashing when it does occur.
If you'd prefer handling it differently or addressing it on the
compositor side instead, I can adjust

[PointerDilemma]

Should be fixed in the linked hyprland PR

[B2krobbery]

Got it, thanks for the fix and for looking into this.
That makes sense fixing it in the compositor is the better approach.