xapp-sn-watcher: an item whose initial GetAll fails becomes a permanent broken placeholder

Last of the defects found in the investigation behind #210, #211 and #212.
Filing as an issue rather than a PR because the right recovery behavior is
a design decision worth discussing first.

When an SnItem's initial GetAll call fails, get_all_properties_callback()
frees the error and returns. Nothing ever revisits the item:

• the status icon keeps the placeholder sortable name it was constructed
  with, and never gets an icon, tooltip or menu
• a client in this state typically emits no NewIcon/NewStatus signals
  either (if its object were reachable enough to signal, GetAll would have
  worked), so no future event triggers another property fetch
• the item stays registered and published, so the panel renders a
  broken-image glyph for the lifetime of the application

This is what #208 and #209 report from the field. Electron 43.3.0 through
43.4.0 shipped an SNI implementation that did not answer the watcher's
property fetches (electron/electron#52952), so GetAll failed once and the
icon was dead for the whole session, every session, which is also the
mechanism behind signalapp/Signal-Desktop#7995 "persists across reboots".
One correction to #209's analysis: the watcher never issues per-property
Get calls, only GetAll through its property proxy, and the missing
/dev/shm/xapp-tmp-*.png in that report shows the watcher's own GetAll
failed even though manual queries addressed differently succeeded. The
per-property Get behavior is a symptom of the same broken client, not the
path the watcher takes.

Electron fixed their regression in 43.4.1, but the one-shot fetch also
loses two ordinary races against perfectly healthy clients:

• a client may register before its /StatusNotifierItem object is fully
  exported, so the watcher's GetAll arrives too early and fails, even
  though the client is fine a moment later
• the GetAll uses a 5 second timeout, and the time this matters most is
  session startup, when every autostarted tray app is initializing at
  once; a busy client can miss that deadline exactly once and currently
  pays for it with a dead icon for the rest of the session

Suggested behavior, combining recovery for the transient cases with
graceful degradation for the permanent ones:

1. Retry the failed fetch a few times with a short backoff before giving
   up. This recovers both races above.
2. Keep the icon hidden until a property fetch has succeeded, so a client
   that never answers (like the broken Electron versions) degrades to an
   invisible entry instead of a permanent broken-image glyph in the panel.

A third option would be to drop the item entirely on repeated failure,
but that seems worse: a client that recovers later (emits a signal,
answers a subsequent fetch) would be gone for good, since nothing
re-registers it.

Happy to put together a PR along these lines if this direction sounds
right.

Start with get_all_properties_callback() and trace the watcher’s item registration and property-fetch path. Decide how retries and backoff interact with failed GetAll calls, then verify that items remain hidden until a fetch succeeds and can recover when a later fetch or signal works.