OK, wordy response here;
Last time I uploaded to Kindle (and it was a year ago) all that information was asked for by Amazon anyway—and I used an upload format that couldn’t have saved the info in the file. So Amazon populated that info themselves from the questionnaire I had to fill out.
That said, I’ve been playing with ebook compile in epub3 format , and yeah you probably need to insert the title, and perhaps the other fields that might be relevant. Not for the content inside your book (headers, title page, etc.)— for those my remarks above still stand. But for the book data that shows up inside ibooks or kindle when your book is closed and you’re looking at it on the virtual shelf.
As for the inside content, the way that works is that the title and the abbreviated title from the project compile metadata pane are assigned to the placeholders $projecttitle and $abbr_title, respectively. Those placeholders show up in the default front matter that Scriv provides in its project templates, and inside the default compile formats in places like the page headers and the section formats. During compile, Scriv substitutes what’s in that project metadata pane for the placeholders.
What I do before using a standard compile format is make a copy of it, and in the copy change every instance of either of those to $compilegroup. I need to look at each section format and at the page format and change that if needed. If I borrow front matter from the default templates, I need to check there, too. Now, instead of using the metatdata pane info, Scriv will substitute the name of the compile group in for $compilegroup, where the $projecttitle or $abbr_title used to go before my edit. Because I run four compile targets, three of which do NOT access any data from the project metadata pane directly, I can do a lot of consolidation.
That said, I’m looking at epub3 because, well, Amazon. I’m really rather pleased. Now that I’m getting over the fact that “Compile-as-is” is a non-starter in epub3, I think I’m going to get a better-looking product.
One thing that IS rather cool that’s new in Scriv 3 is the ability to automatically open your compiled output in an app of your choice at the end of compile. I have this now turned on and will immediately see a proof copy of my real output every time I compile! It’s a great way to check and make sure I didn’t leave anything out of that pesky right-hand pane. 
Since it’s forced in my face, as it were, I can’t send it out without seeing it. Like you, I sent stuff with errors last year (not horrible errors, but errors) and I’m happy to have yet another tool to catch them.
Regarding the TOC file name: I just name them all “Contents” and keep them in different front matter folders. Since the front matter folder I’m using is right there on the first tab in the Project Compile settings area, I’m not likely to forget it. Problem solved.
BTW, if you’re new to Scrivener, there is absolutely no need to give different titles to each doc or folder other than for your own reference. Each document is identified internally with a UUID that you don’t ever want to have to see. I’ve got tons of Dedication, Contents, Title, and Copyright files, in my different little front matter folders I’m trying to consolidate. There’s no need to number files to keep them straight because Scrivener just leaves them where you put them in the binder.
