Emacs' package.el always downloads the highest versioned package it can find, and I don't know a way to stop it from doing so, in general. You can, however, specify which repository your package comes from, using the package-pinned-packages variable, available through the customization menu for Emacs >= 24.4. I use it to "pin" packages I use to MELPA Stable rather than MELPA, for example. If you don't, and you update, say, zenburn-theme, you will always get zenburn-theme version 20151003.2346 (or whatever version is most current) in MELPA rather than version 2.2 (today's most current) from MELPA Stable. (I have both archives in my package-archives list.) This way I at least can make Emacs stick to something a package author has marked as a stable version, not the latest commit he or she has made to Github.
This helps with versioning to a small degree, but doesn't really answer your question, since you are trying to keep package.el from downloading anything that will shadow your built-in package. Unfortunately, package-pinned-packages will only let you specify a repository listed in package-archives. Emacs' "built-in" package archive isn't listed there, at least on my Emacs 24.5, so that isn't an option for your situation. (Emacs maintainers: how about putting a "built-in" archive in there by default?)
You say you have a function for batch install of all packages, so presumably you don't mind writing a little lisp code. Emacs 24.5 (and maybe earlier) package.el has a function package-built-in-p which will let you test whether a package is built in or not. From the documentation,
Return true if PACKAGE is built-in to Emacs. Optional arg MIN-VERSION,
if non-nil, should be a version list specifying the minimum acceptable
version.
This lets you specify a minimum acceptable version, but not a maximum acceptable version, or even (I wish) a particular version. You can use it to determine whether a package in your batch list is built-in or not, and exclude it from your list if it is. Or you could just exclude it from your list and uninstall the version you already have in your elpa directory, as a previous poster suggested.
You could set up your own local package archive, put your preferred version in there, and pin your package to local. This way you get total control over the versioning. See How can I set up an Elpa server? for directions. Now that I think about it, this may be a good idea for many reasons...
(require 'cl-lib)?requirestatement just above the package installation code, however, this did not solve the problem.