Maybe check your tab stops with Format/Options/Show Invisibles enabled. Apple is going to export indents as a literal tab character wrapped in a span that is CSS marked to show as pre. Thus, you should get roughly the same amount of space out of a tab that you would get if you used a
environment to show the code block—it won’t in my experience, have anything to do with your tab stop settings in Scrivener—tabs don’t really map well to HTML, as a concept, as you probably know. So setting them to roughly match the Kindle output, in Scrivener, may be beneficial, but not essential.
And again, that option to export source files can be really handy for figuring out what is going on at the HTML level of the e-book. You should be able to see exactly what is happening with the indents by examining that corresponding HTML file. Incidentally, you can also use that source folder create your own hand-tweaked book, which is the real reason for the feature. Just open the .opf file in Kindle Previewer to turn that folder into a Mobi. If you find that hand-tweaking the CSS files after compiling gets the best look, that’s how you would do it.
Note once you get a code block working the way you like, with the font, tab stops and Preserve Formatting, you can turn the whole thing into a preset. Use Format/Formatting/New Preset from Selection.
Okay, one thing you should be aware of is that this method Apple uses, although it is a perfectly valid and legitimate use of HTML and CSS, does not work properly on all readers. If you’re just focussing on Kindle right now, you should be fine. This method works on I think all Kindles, definitely all modern models. I know only of conflicts with some potentially older Nooks. It will treat the whole line as
if even a part of it is spanned that way, so word-wrap is disabled for any line with a literal tab character in it. We periodically get reports from people that use literal tabs to indent their paragraphs. For your purposes that might be okay if you keep line lengths short, though.