Ignore rules (like those in .gitignore) only apply to untracked files. Changes to tracked files cannot be ignored. There are mechanisms people like to suggest for this use case, but they all cause more trouble than the solve.
(And we know that the file in question is tracked, because git tells you it's modified. That means there's a version of the file already in the index.)
If you remove the file from the index then ignore rules can apply. That means that from this commit forward, the repo contains no version of the file. If you want ignore to successfully cover the entire build directory, you could say
git rm -r --cached build
Of course if the file still exists in other "current" commits (i.e. on other branches), then it will still be there (and could sneak back into your current branch by way of merges).
If you never meant the file to be there and can abide a history rewrite, you might consider using BFG Repo Cleaner to fully get rid of it; but it is an extreme solution that will change commit ID's and require any collaborators to replace their repos.
As an aside, there is basically no reason to ever put .gitignore itself in the .gitignore file. Normally you want ignore rules shared as part of the repo, but if you don't you can use .git/info/exclude instead of .gitignore.
You also don't need separate entries for path-based exclusion and extension-based exclusion, unless files with the given extension exist outside the given path.
