Discover sensor bundles from the SDK catalog, not a product list

The picker listed a hard-coded product list and treated any *.json beside sensor.json as a
configuration, so a folder of stray JSON could be offered as a sensor. Discovery now scans the
shipped root and a writable user root beside it, keeps the SDK's verdict for every entry
(listing rejected ones with their reason) and flags duplicate profile_ids instead of shadowing
them; verified by shared/tests and apps/studio/tests.

shared/src/orisys_app_shared/paths.py

@@ -92,6 +92,34 @@ def sensors_dir() -> Path:
     return config_dir() / "sensors"
 
 
+def user_sensors_dir() -> Path:
+    """The writable user bundle root: a **sibling** of the shipped one.
+
+    The app ships as a portable folder, so the natural place for a bundle the
+    operator adds is beside the shipped ``config/sensors`` rather than inside it:
+    an upgrade that replaces the shipped tree must not delete their work, and a
+    zip that is unpacked somewhere else must carry it along.
+
+    This is only the preferred location. Whether it can be written — and where
+    the catalog goes when it cannot — is decided by
+    :func:`orisys_app_shared.sensors.bundle_catalog.resolve_user_root`, which
+    reports the root actually in use. Never place user bundles in the shipped
+    root, and never in Documents.
+    """
+    return config_dir() / "sensors-user"
+
+
+def fallback_user_sensors_dir() -> Path:
+    """The per-user bundle root used when the portable sibling is not writable.
+
+    ``%LOCALAPPDATA%\\OrisysStudio\\config\\sensors-user`` on Windows, and the
+    equivalent cache root elsewhere — the same derived-data area
+    :func:`derived_data_dir` already owns, so a read-only installation medium
+    still has somewhere writable to keep the operator's bundles.
+    """
+    return derived_data_dir() / "config" / "sensors-user"
+
+
 def locales_dir() -> Path:
     return config_dir() / "locales"