Idle inhibitor: should it reset at login or on resume from suspend?

Split out from #1483, where I asked for this ambiguously. Raising it separately because it changes existing behaviour and I'd rather have a maintainer decide the default than settle it inside a feature PR.

### Current behaviour

`idleInhibited` is persisted in `session.json` and restored on shell start, so keep-awake survives a shell restart, a logout/login, and a reboot. Nothing clears it on resume from suspend either. It ends only when the user turns it off — or, once the timer work lands, when a timed inhibit reaches its deadline.

### The question

Should the inhibitor reset to off when the session becomes active again — at login, on resume, or both?

**For resetting:** you always return to a known state with your configured lock and sleep timeouts in effect. An indefinite keep-awake surviving a reboot is easy to forget about, and the machine then never locks or sleeps.

**Against:** idle inhibit doesn't prevent lid-close suspend. Turning on "keep awake for 4 hours" for a presentation, closing the lid to walk to the room, and opening it again would silently clear the inhibit and let the screen sleep mid-talk.

Worth noting that the timer work softens the case for resetting: you can now pick a bounded duration instead of leaving it on indefinitely, so the forgotten-inhibitor scenario is easier to avoid without a policy change.

### Options

1. Leave as-is.
2. Reset at fresh login only — distinguishing a login from a mid-session shell restart needs a marker in `$XDG_RUNTIME_DIR`, the pattern `AudioService.playLoginSoundIfApplicable` already uses to avoid replaying the login sound on every restart.
3. Reset at login *and* on resume.
4. Make it configurable.

Option 3 was prototyped during the timer work and backed out — it changes shipped behaviour and the right default wasn't obvious enough to decide there.

Start by reviewing the idle inhibitor persistence around session.json and the login marker used by AudioService.playLoginSoundIfApplicable. Compare the existing login, shell-restart, and resume paths before deciding which behavior should change. Done means a maintainer-approved default and an implementation scope that covers the selected lifecycle events.

Written by the indexing model from the issue text.