happens to noone except me i guess

happens to literally everyone. When you practice problems of the right difficulty you should feel like you're constantly struggling, because that's a sign you're actually improving.

You can even struggle on problems far below your skill level. As a red I'm still not immune from struggling on the occasional div2A (for example edu round 100)

As the author of the problem in question I wanted to make some comments.

The editorial for the problem is devilishly simple, misleading people into thinking the problem was easy. I don't think the problem was that easy in practice, as evidenced by the submission count. While I didn't expect the problem to be so hard (and indeed most testers solved it), the problem was indeed hard for a div 2C.

During testing I made the comparison to 1450C1 - Errich-Tac-Toe (Easy Version). As you can see by the blog comments, it was certainly not an easy problem by any means, but after one simple observation (spoiler!) it becomes a lot easier (in fact, the observation is similar in some ways). (This is also why 1. the constraints for my problem are so small, to allow other solutions, and 2. problem D was only 1750 on the scoring distribution, to encourage people to try it as well [I think it's a lot easier to make progress on that problem FWIW.].)

It is easy to miss these observations, but just because the solution is short doesn't mean the process of getting there should be, too. There are so many things you can try in both problems, how do you know which will work out and which don't? That is problem-solving: building intuition for these types of problems so you see the same ideas later.

Contrary to what you mention, everyone goes through the phase when they just can't solve a problem, read the editorial and go "how didn't I see that?!?". This is part of the natural process of problem solving.

So TL;DR don't beat yourself up about it, short solution $$$\neq$$$ easy to come up with.

easy to implement != easy to think

and 30 mins later u ahve no clue how to solve even though u have thought hardly about the problem

Solving Div2C problems in less than 30 minutes would make you at least a specialist on codeforces. I think that you are giving up too early and maybe don't have enough patience. Spending more than an hour on a problem isn't very uncommon. A better question is: what did you use these 30 minutes for? Were you just staring at the text of the problem statement and thinking?

I didn't have enough time to solve that problem C during the contest, but I upsolved it later without checking the editorial. How did this work?

long fancyadd(long a, long b)
{
  long c = 0;
  long ans = 0;
  long mul = 1;
  while (a > 0 || b > 0 || c > 0) {
    long digita = a % 10;
    long digitb = b % 10;
    long digitc = c % 10;
    a /= 10;
    b /= 10;
    c /= 10;
    ans += ((digita + digitb + digitc) % 10) * mul;
    c += (digita + digitb + digitc) >= 10 ? 10 : 0;
    mul *= 10;
  }
  return ans;
}

long fancysub(long a, long b)
{
  long c = 0;
  long ans = 0;
  long mul = 1;
  while (a > 0 || b > 0 || c > 0) {
    if (a == 0 && b == 0) {
      return -1;
    }
    long digita = a % 10;
    long digitb = b % 10;
    long digitc = c % 10;
    a /= 10;
    b /= 10;
    c /= 10;
    ans += ((30 + digita - digitb - digitc) % 10) * mul;
    c += (digita - digitb - digitc) < 0 ? 10 : 0;
    mul *= 10;
  }
  return ans;
}

Please note that I wasn't just staring at the screen for X minutes and then having a sudden divination: "Oh, yeah, that's the necessary observation". The time was spent writing and testing different pieces of code, each of them providing extra information and moving me closer to a working solution.

I actually enjoy Google Kick Start contests, because they motivate participants to at least try implementing solutions for small constraints, rather than giving up completely if the problem seems to be too difficult. A naive bad time complexity solution can be sometimes used as a foothold for implementing a better solution. There's an old blog https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ and it talks about interesting things: "Maybe this is the key to productivity: just getting started. Maybe when pair programming works it works because when you schedule a pair programming session with your buddy, you force each other to get started."

That said, just being able to solve problems in principle is not good enough. We need to solve them very fast before a contest ends if a good rating is desired. And speed improves with experience, because many competitive programming problems are solved by similar tricks.