The problem here is that git bisect is branch aware. When you tell it that “dependent” is good and “test” is bad, and one of the changes between there is a merge commit, it knows that in order to figure out where the problem was introduced, it’s going to have to look at commits a, b, and c – otherwise, all it would be able to tell you is whether or not it’s broken as of that merge commit.
It sounds like what you’re expecting is to test the combination of commit b with the changes from the other branch, which is content which doesn’t exist in any commit, and git bisect only lets you test commits! In order to test that content, you’d have to do a series of test merges – check out b, merge dependent, let you test, then check out a or c, merge dependent, let you test again. You can very easily do git merge --no-commit dependent once it’s left you at commit b, then do git reset --hard when done with testing before running git bisect good/bad.
Otherwise, if I’ve misunderstood you expect it not to test any commits on the merged branch, and only test the merge commit itself (you don’t care which of a, b, or c broke it), simply tell it that everything on the merged branch is good. Even better if you know that a, b, and c have nothing to do with it. Then you know without even testing that they’re good!
But the one thing that you can’t expect is for git to completely ignore commits a, b, and c. It has absolutely no way of knowing whether or not their changes are relevant to your “bug”, and their changes are part of the difference between your good and bad commits.