You have a few options, in random order:
1. Different authentication schemes
Web browsers frequently authenticate by session identifiers in cookies. Many native apps attach auth tokens directly in the request header (in an
2. Client side certificates
This probably isn't worth the trouble, but if you enable client identification via client-side certificates (and do it properly) then you can be certain that the person on the other end of the conversation is an app, not browser, and disable CSRF validation.
3. Custom headers
One potential strategy would be to include a custom header with the request from the native app, and disable CSRF protection if present. This is likely a safe strategy. Further reading here:
CSRF protection with custom headers (and without validating token)
4. Anonymous requests
You asked about doing this is an anonymous manner. To some extent (aka this is not 100% applicable) anonymous requests don't need CSRF protection because the whole point of a CSRF attack is to take over a user's session. If a user is anonymous and not logged in, then there probably isn't much to take over anyway. An application without logins, which stores no state as a result of client actions, doesn't really need CSRF protection in the first place (although I may have misunderstood what you meant there).
5. Separate Endpoints
I think this is what it really comes down to. If you have an endpoint serving two different clients in two different ways, then I think the issue is that you need two endpoints, one with CSRF checks disabled and one with them enabled. Of course this only actually works if the two endpoints are authenticated differently, which really just brings us back to item #1. If you have two separate endpoints, one for native (with CSRF disabled) and one for web (with CSRF enabled), but both accept the same cookie for authentication, then an attacker can perform CSRF attacks the second they realize that that native API exists and accepts the same cookie as the web.
Ideally I think you should have two separate endpoints. Even if the two perform almost exactly the same action, you can always just structure your system so that you use the same basic code to fulfill both API calls, but they have separate endpoints and separate authentication logic. Of course the other option would be to have one endpoint meant for both systems, that operates exactly the same for both. Having one endpoint that tries to operate differently for two different systems is probably the easiest way to get yourself in trouble.
I didn't hit up your questions point-by-point, but I believe these are effectively all the options you have, so hopefully it answers your question anyway.