is AES-128-CBC then SHA-256 more secure than AES-128-GCM?
They are not at all comparable. SHA-256 is not a MAC! A MAC requires a secret. AES-128-CBC with an HMAC-SHA-256 on the ciphertext would be more similar to AES-128-GCM, but GCM would still be preferred simply because it gives you less opportunity to screw it up.
I tried to use AES-128-GCM, however I did some simple modification in the ciphertext before decrypting, just appended some bytes to the ciphertext, and found that it decrypts successfully
This sounds like you are either using the library incorrectly or the library has a bug. What is the library, and do you have an example that reproduces the issue?
AES GCM is authenticate then encrypt algorithm?
Not really. I'm not completely sure about the terminology here, but I don't think it's really considered MAC-then-encrypt or encrypt-then-MAC, it's in a separate class of AEAD modes that include a MAC in the encryption algorithm instead of before or after it. I'd say it's closer to encrypt-then-MAC though, as you can see in the diagram on Wikipedia it is the ciphertext that gets fed into the GHASH function, not the plaintext.
encrypt then authenticate feels more secure to me
See this question about encrypt-then-MAC vs MAC-then-encrypt. Encrypt-then-MAC is generally recommended, as it prevents things like the padding oracle attack (if done correctly), however you also have to be aware of things like not forgetting to include the IV in the MAC. You should not be doing this yourself, you should use a library that handles all of the "crypto stuff" for you.
AES GCM authentication even secure enough to be compared to SHA256 for example or is it CRC tier for quick integrity
As stated previously, SHA-256 is not a MAC, but the best comparison I found of HMAC-SHA-256 and GHASH is here. HMAC-SHA-256 truncated to 16 bytes seems to be secure to the full 128 bits, while GHASH's security is dependent on the ciphertext size. If an attacker tries to forge a 1 block ciphertext it has a 1/2128 chance of succeeding, however if they try a 232 - 1 block message (the maximum size for GCM) their chance increases to about 1/296. This is unlikely to matter in practice, as 296 is still prohibitively large, especially given that it requires using a many gigabyte ciphertext.
The other thing to remember about GCM is that its authenticity is reliant on unique nonces. If a nonce is ever reused you can no longer trust the authenticity of messages, which is a concern if you're not extremely confident that nonces will never be reused. The tradeoff is that GCM is generally much faster than CBC+HMAC, which is why it's usually preferred by TLS where keys are short-lived (making nonce reuse even less likely). As explained here, as long as you use either a 12 byte counter that you are very sure will never roll back (eg due to hardware failure) or a random 16 byte IV you should be fine.