Sensor settings should be declared, not created as a side effect of reading them

[TimoPtr]

Description

SensorManager.getSetting persists the default value into the DB when the setting is not stored yet. The sensor detail screen discovers which settings exist from the stored rows (getSettingsFlow), so a setting only becomes visible once some code path happens to read it. This write-on-read side effect is the root cause of #6773 and forced the workaround in #7206, where requestSensorUpdate calls a getter and discards the result purely so the write happens.
#7040 already removed this pattern for the sensors themselves: the repository returns the default when nothing is stored, and only an actual change is persisted. Settings should follow the same model.

Proposal

• Sensor managers declare the settings each sensor offers (name, type, default, entries), similar to how available sensors are declared via getAvailableSensors.
• The detail screen merges the declaration with the stored values, so settings are visible immediately without a DB row.
• getSetting returns the stored value or the declared default, without writing. Only user changes persist.

Benefits

• Removes the initialization workaround from Fix notification sensor settings initialization #7206.
• Fixes the same discovery bug for active_notification_count (its SETTING_INCLUDE_CONTENTS_AS_ATTRS toggle only appears after a notification callback) and for any other sensor whose settings are only read in event-driven paths.
• Settings behave consistently with sensors after Implement SensorRepository on top of SensorDao to handle default #7040.

Additional context

No response