@NamespaceV —
1. Spellbook, FTV, etc.
The "Mass Input" tool in Editions is only available to premium users. However, the "Add Card List" tool in Inventory is available to free accounts. Go to your Inventory > Add Cards > Add Card List, then set the Default Values to e.g. From the Vault: Angels, Mint, English, and Foil. Copy'n'paste the list of 15 cards from anywhere on the internet, and voila. Added without issue!
2. Dropbox vs. Github
Alright, you guys have convinced me! I'll work on making my transition to Github. Thank you for the PR; that gets me a headstart. And yes, 440 files is the correct amount.
I do think that Github is complete overkill for the CSVs. Based on everything both of you have written, the main benefit seems to be C) organization, allowing people like you guys who are familiar with Github to just download the entire batch of CSVs at once.
The other semi-benefit is keeping track of who submitted and who marked a CSV as verified, in order to maintain quality control. That has been a non-issue up until now, since almost no one has been contributing CSVs. But perhaps this is the start of a new era. 
3. UI
I think you underestimate my knowledge. LoL. I am very familiar with separation of content / layout / styles / behavior, and always try to code in that paradigm. The current hardcoded data is a relic of my training, though. It was drilled into me to always start with a functional page, even for people who have Javascript turned off (and I always thought it was so incredibly stupid that we have to cater to people who don't want to enter the modern age, but anyways.....). So I created the page to look and work fine with or without Javascript. Then I use JS to transform some aspects of the layout onload.
But I agree with you that it's reached a point that I'd rather separate the data and dynamically create the layout. When I first designed the page, it was a much smaller amount of data to wrangle! I'm fluent in using JS/jQuery to create layouts, so I'll be updating my scripts soon to make everything dynamic.
By the way, the only reason I concatenated all the extra info in the script update I gave you was just so it worked in the current table layout you had. I trusted you would be very capable of adapting the code and altering your table layout if you so chose.
4. Cooperation
Thanks again for taking an interest in this project! Before accepting your PR, I have a couple questions:
A. On Github, what is the preferred organization for an extensive repository of CSVs like this? Organize them in multiple subfolders based on precon type, or prepend that info to the filenames while keeping them all in one folder? Currently, my Dropbox has them all in a subfolder hierarchy, so it would be pretty easy for me to just copy that hierarchy to Github.
B. The reason I started using Bitly is because I wanted to see data on how often various products were downloaded, as well as things like whether people were tending to download e.g. individual Commander decks or the bundles like C20 - All 5 Decks. (I also liked that the Bitly links were much shorter and nicer to glance through in the source code than the native Dropbox links. But that would also be true using Github.) If I were to switch away from my Dropbox/Bitly setup, what would be the easiest way to continue this data collection on CSV downloads? I've never used Google Analytics, but from my vague understanding of it, the free account limits how many things you can track, so I definitely wouldn't be able to track all 440 (and growing) links.
5. Jumpstart
Can you think of anything better than the current system I've implemented to figure out what packs you have? In the current setup, it's easy to drill down to the correct color and pack name. Then it's just a matter of figuring out which variant you have. I did this by analyzing all the decklists and determining a unique card (or combination of cards) that makes that variant unique from the others. So if you have the Jumpstart pack in front of you, you look at the card name(s) on the website and see if it's in your pack. If so, that's the correct CSV to download.
For example, say you have an "Above the Clouds" pack. You know it's blue, so you go to Jumpstart > Blue and find the Above the Clouds variants under Common Packs. You notice you have both Inniaz, the Gale Force and Warden of Evos Isle in your pack, so you download the first variant. Now, Clouds 2 also has Inniaz... but it doesn't have Warden. And Clouds 3 also has Warden... but it doesn't have Inniaz. So the only possible pack it could be is Clouds 1, which has both.
I can think of no better system than this, since the Front cards in the packs aren't labeled in any way to let you know which variant you have. And you certainly don't want to look through an ENTIRE pack list! I guess you could start typing in card names in a box, and it would filter to the one you need? But that seems like more work for users than the current system.
=========================
@HeyMerlin — I'm curious about this statement you made: "Having the CSVs on github makes it easier for me to browse them rather than downloading them individually." You're either browsing them in an ugly tabular layout on Github or browsing them through categorical dropdowns.... but either way, you're having to browse to find the one you want, correct? And then unless I'm missing something on Github, you have to download the CSVs individually there, too (is there a way to select multiple files and download just those as a ZIP?). Or I guess you can download/clone the entire repo and do all the browsing on your computer. So unless I'm misunderstanding you, it sounds like it has more to do with the browsing experience. You'd rather a table than dropdowns?
As to your other question: A CSV creation guide is a great idea! Thank you for suggesting it. As someone who does it all the time, it didn't occur to me that saying "make a CSV and send it my way" would be a hurdle. But duh, of course it would. Heh.
Honestly, anywhere you trust. I actually use MTG Wiki quite extensively and contribute to it myself, but you could just use info from the mothership. Easiest way to find decklists on Wizards' website is through Google.
I'll create a CSV template for download, though I suspect downloading a filled-in CSV might actually help a person understand it better.
As to columns, the absolute minimum we need is Count, Name, Card Number (for artwork variants when the card appears more than once in the set, such as basic lands), and Edition. The Foil column is only required for precons with foils in them, and Language isn't strictly necessary, though I made the decision early on to have all CSVs default to English. (Originally I had a Condition column and would set it to Mint, assuming unopened precons, but many people have opened and played with their precons, so I simply removed the condition column entirely and leave it up to the individual to set.)
As to sections within the CSV: No, it doesn't negatively affect import. As long as nothing is in the Count column, Deckbox will ignore that row entirely. So I started dividing decks, thinking some users might find it useful, such as in the case of Event/Challenger decks that have sideboards — nice to see what the sideboard is supposed to be! But having sections is definitely not necessary, and most of the CSVs are older additions and don't have any sections.
You know? I've never tried it without proper capitalization, but I imagine it would work. The most important guideline for the CSV is simply... does it import without error?
That said, I personally prefer proper capitalization, and the editor inside of me will probably feel compelled to go correct everyone's capitalization, so.... for my sake, please. 
I also like the columns to be in the order I have them. The order doesn't technically matter, as it'll import with any column order, but I think keeping a consistent layout is smart, especially considering all the discussion of future migrating/merging/updating.
You've already identified the only necessary "keyword" and its correct usage. For any of Deckbox's flags (this goes for misprint, altered art, signed, etc), you either leave it blank or include the appropriate word to set the flag to true. If you leave Language or Edition blank, then it'll be imported without that value set. If you leave Card Number blank, Deckbox will choose a card number to set. A blank name will throw an error, and a blank count will mean the row gets ignored, as mentioned above.
Whether or not it's verified is required info. If a CSV is submitted without this being specified, I'll add it as unverified. How it's verified hasn't mattered to me thus far, but once we migrate to Github, there's no reason this info can't be included, as it'll help vet the CSVs. And if it's ever discovered that a supposedly verified CSV is actually not accurate, we'll know who to blame!
Some examples: Say you opened a commander deck and did nothing to it except replace the basics with full-art lands, throwing all the basics into your basic land box. Since you can now no longer know with 100% certainty which exact lands originally belonged in that deck, you would mark it as unverified. But you can add a note stating that the rest of the contents were verified. What about an old theme deck that's been stored loose in a box next to some other decks / cards? Use your best judgment. If you feel confident none of the cards got separated or mixed up despite being loose, then mark it verified and specify it was verified by your opened copy.
The verification method I've come to prefer is unboxing videos. Unfortunately a lot of YouTubers will skip past the lands, but I've found a few sources that do a good job showing even the basic lands.
Thank you as well for your interest, and looking forward to your contributions!
