Did my master’s on state estimation before I drifted into IT, so this one I can answer.
Rahul is right that you check rank, just locally. Linearise at the current estimate: F = df/dx, H = [1 0 0]. Build O = [H; HF; HF^2] and check its rank (or better its condition number) along the trajectory. With your model, the q_in and k columns of HF are dt/A and -dt/A*sqrt(h). They’re independent only if sqrt(h) changes over the window. When the level sits still, O drops to rank 2 and the filter can trade q_in against k forever, which is exactly what you see.
What I’d change:
Give the two states different time scales. k changes over months, q_in over minutes. Make the process noise of k tiny (orders of magnitude below q_in) so the filter only moves k when there is evidence.
Use the excitation you have. When the pump runs, Q_p is known and the level moves, which is when k becomes identifiable. Some people only update k during pump cycles and dry-weather periods where q_in is near zero.
Keep k positive: estimate log(k), or clamp it.
If budget allows, one outlet flow measurement once a week (a portable meter) pins k and the problem goes away.
For the ops board, send the diagnostics too, not just the estimates:
{"h_m": 2.41, "q_in_ls": 38.2, "k_est": 0.0164, "innov_m": 0.004, "obs_cond": 1.2e3}
A chart of the innovation and the condition number tells you when to trust k. An alarm rule on obs_cond above some limit with a duration debounce is a cheap way to flag «k estimate unreliable right now».