reversing hash function makes possibilities increase exponentially, yet there is a finite number of inputs. How?

When trying to reverse a hash function, there is loss, e.g.

a+b=c
given c=5, try to go back to a,b (previous step)
(a,b)=(5,0),(4,1),(3,2),(2,3),(1,4),(0,5)

but, given any of the (a,b) pairs, we get c=5 in the next step, and each of these pairs have the same exponential growth applied when reversing them. Thus, it seems that every step back you take increases the number of possible values that lead to c=5 exponentially.

Also, no two branches can recombine when reversing, as that would require one (a,b,c) to split into two possible (a,b,c), which is random not deterministic and so impossible in hashing.

The problem is, there is a finite number of inputs, and a finite number of possible (a,b,c) values. It seems like a paradox, and the only solution I can find is that some paths are dead-ends, e.g. ((a,b,c)!=possible to make from any other (a,b,c)). Yet I don't think any such (a,b,c) exists, so maybe I have the wrong solution?

Every step back increases the number of possible values exponentially if there is no significant overlap between the branches. And if a hash function has no collisions, then there is no overlap.

But if you make many steps back, the approximation that a hash function has no collisions is no longer accurate. A cryptographic hash function does have collisions. We can't feasibly find one, but they exist.

By the time you've made so many steps back that there is significant overlap between the branches, the number of branches has increased exponentially to the point where it's infeasible to store all of them. If you had practically infinite computing power, you could reach that point. But cryptography does not defend against adversaries with practically infinite computing power, only against adversaries with realistic computing power (it's generally considered acceptable if the adversary would need to use all the computers now existing and would need to wait for longer than the universe has already existed — that's roughly what 128-bit strength gives you — though some applications go further to the point where all the energy of the galaxy wouldn't be enough for the attacker, which 256-bit strength gives you).

reversing hash function makes possibilities increase exponentially, yet there is a finite number of inputs. How?

That is quite what we expected ( the short story); each unknown increases the possibility by 2, therefore you will get an exponential - you may think the truth table to see that. There is finite input to SHA-256 due to the padding rules, that is $2^{128}-1$. Your input may not be that large, still finite.

Reversing the SHA-256 hashing operation with solving equations ( we call this algebraic attack) is almost impossible since you must solve a symbolic computation (SAT) and 3SAT is NP-Complete. There is no guarantee that every SHA-256 instance is intractable. When we consider that AES's claimed algebraic attack (XSL) is not faster than the brute force. I expect that the 64-round of SHA-256 will be harder to cryptanalysis with algebraic attacks. This still doesn't imply that for some hash values the instance will be intractable, too.

Even for 64-bit input space, I expect that algebraic is harder than searching the 64-bit input space to find the pre-image of the given hash output.

In your calculation, you are eliminating some possibilities of the variables, this is what we expect, however, the 64 round of the internal block cipher of SHA-256 named SHACAL2 will not let you execute it much. This is not the way to attack SHA-256.

Bard's book; Algebraic Cryptanalysis is a starting point to the algebraic attack. And, see how their novel notice help to break the simple keeloq encryption while SHA-256 is much more complex to be considered.

I think your confusion comes from looking at a single operation instead of a hash function as a whole. It's true that reversing an operation such as addition introduces another input variable for each iteration. But that ignores the way such an operation is used within a hash function. If you look at a function like SHA-256, an operation like addition fits within a well-defined network of other operations that transform the inputs to the outputs. The network accepts 512 bits of input and produces 256 bits of output, and the definition is fixed, so there's not really any room to talk about "exponential growth". What is true is that attempting to solve for a set of inputs that produces a desired output is expected to take effort exponential is the size of the problem.