A backstage shell restart can leave a stale display in the session registry

[ghostpsalm]

Found by red team during #53, not fixed there — it needs a mechanism decision rather than a patch.

The registry entry for a session records the X display that session published. dreamconnect-register@<uid>.service writes it once, at unit start. If the backstage shell restarts and its Xwayland picks a different display number, the publisher rewrites /run/user/<uid>/dreamconnect-display.env, and the daemon (via EnvironmentFile=-%t/...) and the ScreenConnect drop-in both pick the new value up — but nothing re-runs registration, so the entry still names the old display.

Consequence is worse than a stale label: the entry's shm/socket still match the drop-in's static args, so the agent's known-wrong-fallback rule fires and the session is REFUSED (black) rather than falling back. Before the registry existed this case simply worked.

Why it was not fixed in #53: dreamconnect-register@ is a root system unit and dreamconnect-backstage.service is a user unit, so the obvious PartOf=/ExecStartPost= coupling does not cross the scope boundary without extra privilege. Options worth weighing:

• a systemd .path unit watching /run/user/<uid>/dreamconnect-display.env and restarting the register instance on change;
• the register script re-checking periodically (a timer), which trades promptness for simplicity;
• polkit rules letting the session user restart its own register instance;
• making the daemon itself the registrar via a root helper.

Workaround today: dreamconnect-session backstage re-registers.