Interestingly, the same effect easily happens in the "preview" (the live display on the LCD screen) but never in the final photo. Is the sensor switched between different operation modes ?

The CMOS sensor could be designed to operate in multiple modes. In "preview" it is supposed to spit out rather high frame rate with limited power consumption, so it could use just fixed, common exposure setting over the whole chip. There few pixels may be allowed to saturate, so cause the artifacts (saturating pixel means activating of the 0arasitic bipolar transistors in the structure, jamming the signals).

In photo mode the individual exposure settings is adopted to the actual exposure, so saturation is prevented, so the artifacts disappear. But this takes a bit longer (it takes multiple test pictures to iterate towards the needed adjustments over the sensor area) and more power, so it is used only when the main photo is taken.

I don't understand you much but. You mean that all the cameras generates patterns like this and my camera noise generator is generating a plain texture?

I don't know if that pattern is fix or random. The camera always had this glitch, with the battery fully charged and flat.

I have few theories: 1- There's something wrong with the sensor or the sensor codifier, maybe the design skip some components to make it cheaper. 2- There's not any noise generator for save few CPU cycles. 3- There's something wrong with the noise generator and it's generating this.

Imagine a random number genarator that runs off RTC with millisecond or higher resolution, but the RTC is stuck at "12:00" due to a dead battery (maybe a tiny lithium cell somewhere inside the camera, not the main battery)

In second thought, the randomness there is not used for encryption or anything like that, so it does not need to be "properly" random. So it could be something as simple as a fixed random sequence somewhere in the ROM.... (or even just reading program code area as "random data")

I don't understand you much but. You mean that all the cameras generates patterns like this and my camera noise generator is generating a plain texture?

I don't know if that pattern is fix or random. The camera always had this glitch, with the battery fully charged and flat.

I have few theories: 1- There's something wrong with the sensor or the sensor codifier, maybe the design skip some components to make it cheaper. 2- There's not any noise generator for save few CPU cycles. 3- There's something wrong with the noise generator and it's generating this.

The "random" generator does not have to be truly random at all, it just should not generate regular patterns.
Definitely it wont be any HW defect at all, as those would cause the processor to go mad first, so becoming unable to take any picture at all.
The reason could be either lousy SW engineering (setting wrong parameters for the given pixel counts) or indeed an attempt to save some power by using simpler, less computing demanding algorithm.
But what puzzles me: These dithering effects are usually make sense only on the reproduction (display) end of the chain (the used panel has limited color resolution). They are completely useless when the limitation is the sensor ADC or so (as you have to have the fine resolution image first), so I dont see how it should be affecting the recorded image.
Maybe some dithering magic is in the ADC, but then it could work only in 1-D (accumulating the rounding errors along the stream of processed pixels), but the restriction to 1-D means it would become very visible way before it has any chance to bring any benefit (boost the apparent color depth with limited native sensor depth). But maybe it is exactly that...

Imagine a random number genarator that runs off RTC with millisecond or higher resolution, but the RTC is stuck at "12:00" due to a dead battery (maybe a tiny lithium cell somewhere inside the camera

The RTC runs from the main battery, because when I remove it the hour and date resets. I think that this is a problem with the sensor or the image encoder.

The RTC runs from the main battery, because when I remove it the hour and date resets. I think that this is a problem with the sensor or the image encoder.

The RTC has nothing to do with any of the image processing at all (except of course the time/date imprint).

Those artifacts are just result of how the processing was designed.
Could be some sensor calibration data becoming out of date (not following the sensor aging) or maybe even lost (the sensor may use multiple parallel amplifier/ADC paths, which have to be calibrated for the transitions to not be visible). But as far as I know, this used to work automatically "on the fly". One reason being it does not need any factory alignment, but mainly to make it able to adopt to changing conditions (temperature, component aging drifts,...), so at the end to allow the analog circuits to be way less precise, so simpler, smaller on the die and so cheaper.