I can't really answer this from a SAFe perspective since I'm not very familiar with the framework, but I'll add a general answer nonetheless because I sense some confusion in the way the question was asked (and it's too big for a comment :)).
For example, the "Verify the put API updates correct information in DB" AC that you mention, isn't really an AC. An acceptance criteria is a behavior the application should have or a thing that it should do from the perspective of the product owner/user/client. What does the "put API" do? When you call it what's the expected result? What should happen? What's the new context inside the application? Etc.
User stories, for example, are described by 3Cs: Card, Conversation, Confirmation. In the Confirmation part you have acceptance criteria that gives you the things to look at to ensure that the story is implemented correctly and all requirements are met. A proper AC should be something like "When a product is updated, then the change is consistent across all product pages", or whatever the "put API" does. It's not "the API updates correct information in the DB". It's obvious that the information should be correct in the DB, otherwise your AC can be expanded to say "the new code we've written should have no bugs that cause DB inconsistencies" which isn't very useful. It's a matter of common sense that the developers need to know what they are doing technically. The AC is for them to know that they are building "the right thing" functionally. They can update the DB just fine when building the wrong thing too.
The ACs are agreed upon when discussing the feature and breaking it into stories. It's part of the second C, the conversation everyone needs to have in order to understand what needs to be built. To put it bluntly, it's like asking your product owner "Hey Product Owner, after we build this thing, what will you look at to see if it's the right thing? What will you check? How will you confirm that this is what you wanted?".
Based on the conversations, you will then split the feature into stories with ACs on them, or even find some ACs that can stand alone and become stories themselves. You will have ACs on the stories that make up the feature, and maybe some larger ACs on the feature itself too, if the combined ACs on stories don't cover everything. Even if you define ACs at the feature level, the way you do so is by having a conversation and decide on the things that can give you the Confirmation that you built the right thing.
If you are creating an API that allows for CRUD of specific data, and the only way to confirm the feature does the right thing is by looking inside the DB, then that's what you have to do. Bbut be aware, that as I mentioned above, you should consider behavior of the application. For example, your AC might say "the data is updated in the DB correctly", but if there are application caches for example that also need to be invalidated after the update, your AC on the CRUD feature won't give you a Confirmation that the application does what's needed with the new feature in it.
Once you figure out what AC you will look for, you can take things a step further and try to automate some of the ACs with Acceptance Test–Driven Development (ATDD).
As for your last question:
if a dev team encounters a scenario during Increment Planning where it is not comfortable that the feature is fully understood, what are the recommended ways to raise those concerns?
This is part of the second C, the conversation. You should not start implementing a solution until everyone involved understands what needs to be built.
