Then Alice can’t make a Plasma Debit payment to Bob yet. (She could still make a Plasma Cash payment to him by transferring the entire amount of her channel to him.)
The operator could enable this transaction by depositing some of its own liquidity into Bob’s coin, so that that coin now has some operator-owned balance. (This is different from making a payment to Bob—the operator still owns their ETH, they’re just holding it in that coin, next to Bob’s ETH.) But of course, this does requires the operator to lock up some capital.
The operator is like a Lightning hub. When you open a channel with a Lightning hub, you can’t receive any payments over that channel unless either a) the hub puts some of their own liquidity into that channel, or b) you make some payments through that channel, thus reducing the portion of it that you own and increasing the amount that your counterparty owns, and thus your own receiving capacity.
So enabling Plasma Debit payments requires some liquidity commitment by the operator.
Not by default, just by assumption of the above example. When you initially deposit, you own the entire balance in your coin, until you make a Plasma Debit payment, or the operator commits some of their own capital into the coin. The above example assumed that one of those things had already happened, so Bob already had some receiving capacity.
No, there is no trust requirement.
The reason any malfeasance would hurt the operator is that in the example I was discussing, the malfeasance would basically be “incrementing Bob’s balance without decrementing Alice’s balance,” which is equivalent to “the operator paying Bob, without the operator getting paid by Alice.”
So the repercussions for this misbehavior would be that Bob still gets paid, but the operator is the one bearing the cost of the payment, rather than Alice.