rework JsonConf caching/de-duplication to avoid needing a clear() method #1789

Description

JsonConf re-declares clear to opt back in to the type-checker deprecation on prop-removal (be81e8b). Only three call sites use it, and it's worth deciding whether to keep them or encapsulate them. No decision made yet.

The three JsonConf clear() calls

• data/_file_cache.py:20 - the path-based dedup layer. One instance is cached per path and shared by all holders; on (re)load it does clear() + update(parsed) to refresh that shared instance in place, so every holder sees the new data.
• modes/extensions/extension_record.py:158 (reload_state) - state file gone, reset so stale is_enabled/error can't linger.
• modes/extensions/extension_record.py:224 (remove) - after uninstall, reset so old state can't resurface via the cache.

Note: reassignment is not a fix

self.state = ExtensionState() only rebinds this record's attribute. The lru_cache still holds the old populated instance, so the next load(path) (e.g. reinstall) gets stale data. In-place mutation is required because the instance is shared by identity.

The smell

Resetting a shared cached instance is a cache-layer concern, but ExtensionRecord reaches for the raw clear() dict primitive to do it. All three call sites really mean "refresh this shared instance from disk, or from nothing."

Options

1. Encapsulate as a method in _file_cache: reset call (clear + re-apply defaults) that remove/reload_state use instead. Sharing semantics stay in one module; call sites express intent.
2. Swappable box/Ref - refresh by rebind, clear disappears, but rewrites every self.state.foo reader. Likely not worth it.

If clear stops being a public reset path, revisit the JsonConf.clear opt-in. Field-default policy is in docs/architecture/.

Communication guidelines

• I have read and agree with Ulauncher's communication guidelines and checked the existing enhancement requests before suggesting this.

Ulauncher v6

• I have checked and couldn't find my suggestion in v6.