"How can I manually construct a transaction with multiple inputs, or is this done by the blockchain?"
Yes, you can manually construct transactions [on a very fine level] with wallets that allow you to.
For example, the Electrum wallet, [some] web-based wallets, and command-line wallets...
allow you to control the construction of transactions, down to which inputs are included.
This isn't done by the blockchain. It is done by wallets; some wallets will allow you to.
Of course, most wallets don't.
They will select inputs based on a [calculation which will] construct a transaction...
that is not too expensive or bloated.
For example, if you have exact change, then you should use that input to make your payment.
Considering fees, of course.
But if you don't [have the exact amount in one input] and need more than one input in order to make a payment,
because you have [many] smaller amounts in your wallet, then your wallet will construct...
a transaction with multiple inputs.
That is how these transactions are constructed. You don't need to do it, but you can with some wallets.
In many cases, you will see this option in a menu called "coin selection."
Coin selection is the ability to manually construct a transaction with multiple inputs.
"I still don't quite understand the concept of change."
If Satoshi wanted to send ten bitcoin to Hal Finney, why was it a transaction of fifty bitcoin with...
forty bitcoin as change? Why is it not a single transaction of ten bitcoin?"
"Is the input for a transaction derived from the total [balance] in a wallet?"
"Or from the last amount received?"
"In other words, if Satoshi already owned about one hundred bitcoin by that point...
Would the input be one hundred bitcoin, or fifty bitcoin, because that was the last amount they received?"
Right in that question, you have already planted the seed of your answer.
Bitcoin uses a ledger which tracks the last amount received as a unique and indivisible "coin."
We call that the 'unspent transaction output' or UTXO.
An unspent transaction output is the specific amount you received in a previous transaction, to that address.
That specific amount is what you can spend in the next transaction.
You can only spend all of it. Transactions move chunks of bitcoin around.
You can split a chunk of bitcoin into more than one, or join multiple chunks of bitcoin [together].
But every chunk or UTXO that you spend, received from a previous transaction, must be spent as a whole.
Let's [look at your example] here.
Let's say that Satoshi previously received one hundred bitcoin before sending ten Bitcoin to Hal Finney.
How did Satoshi receive this? In two different transactions of fifty bitcoin each.
Each of those transactions created an unspent transaction output of fifty bitcoin.
Satoshi's wallet could spend either one or both of those fifty bitcoin transaction outputs,
by referencing them as inputs in a future transaction.
When Satoshi gave ten bitcoin to Hal Finney,
they didn't have a [specific] chunk of ten bitcoin from a previous transaction.
Satoshi has two fifty bitcoin chunks.
The transaction will [include] one of those fifty bitcoin chunks and split it into two outputs,
one that goes to Hal for ten bitcoin, and one that goes back to Satoshi as change for forty bitcoin.
At this point, Hal has a ten bitcoin chunk to spend. Satoshi now has a forty bitcoin chunk as change.
Therefore, that is what would be available to spend for the next transaction.
Let's say that Hal wants to pay one bitcoin. The only UTXO in his wallet is a ten bitcoin chunk.
In order to pay someone one bitcoin, Hal would create a transaction that spends the ten bitcoin UTXO,
with one bitcoin as payment, and nine bitcoin as change.
Ever [balance] in Bitcoin is basically the unspent transaction outputs.
The unit of currency that exists in Bitcoin is the outputs of transactions,
these chunks that can only be spent as a whole.
When you look at the blockchain from the perspective of a wallet or database, you are looking at transactions...
that have or can happen.
Transaction outputs can only exist in one of two states. They are either spent or they are unspent.
There is no in-between. You can't have a transaction output that is half-spent.
It is easier to manage the database if you simply need to figure out which of these units of bitcoin...
have been spent by [previous] transactions or have not been spent / are available to spend.
If you needed to figure out what part of a previous transaction output is spent or not spent,
it would make the system a lot more complicated, and more difficult to track double-spends.
Everyone validating a transaction would need to perform more work to figure it out.
They would need to look at all of the balance stored in the wallet, across all of the transactions,
just to validate one transaction.
Instead, in this model, if I validate one transaction, I only need to look at the input references...
to see if that particular input has been spent or not.
I don't need to [build] a map [of other addresses]. It has either been spent or not been spent.
That is the only input I need to look at.