fix: apparent error charging interest during liquidation

[turadg]

no ticket, discovered while working on #5558

Description

chargeAllVaults when done calls reschedulePriceCheck. If liquidation is in progress then the highestRatio() vault has no collateral allocated because it's in the seat for the liquidation trade. This was resulting in this error logged:

----- IV.2  5 updateUiState 1 {
  interestRate: {
    denominator: { brand: [Object [Alleged: RUN brand]], value: 10000n },
    numerator: { brand: [Object [Alleged: RUN brand]], value: 100n }
  },
  liquidationRatio: {
    denominator: { brand: [Object [Alleged: RUN brand]], value: 100n },
    numerator: { brand: [Object [Alleged: RUN brand]], value: 105n }
  },
  debtSnapshot: {
    debt: { brand: [Object [Alleged: RUN brand]], value: 389n },
    interest: { denominator: [Object], numerator: [Object] }
  },
  locked: { brand: Object [Alleged: aEth brand] {}, value: 400n },
  vaultState: 'liquidating'
}
----- VM.5  16 chargeAllVaults { updateTime: 4n }
----- VM.5  17 chargeAllVaults complete
🚨 vaultManager failed to charge interest (Error#1)
Error#1: First vault had no collateral
  at Alleged: PrioritizedVaults.highestRatio (.../run-protocol/src/vaultFactory/prioritizedVaults.js:88:1)
  at reschedulePriceCheck (.../run-protocol/src/vaultFactory/vaultManager.js:336:42)
  at Alleged: VaultManagerKit helper.method [as reschedulePriceCheck] (packages/SwingSet/src/liveslots/virtualObjectManager.js:478:43)
  at chargeAllVaults (.../run-protocol/src/vaultFactory/vaultManager.js:283:22)
  at Alleged: VaultManagerKit helper.method [as chargeAllVaults] (packages/SwingSet/src/liveslots/virtualObjectManager.js:478:43)
  at Object.updateState (.../run-protocol/src/vaultFactory/vaultManager.js:785:1)

This moves the query for highestRatio() to lower in reschedulePriceCheck so it's after the existing returns.

It also renames liquidationInProgress flag to distinguish from a particular vault being liquidated. The flag just means that the generator is being consumed.

Finally, it cleans up 633ee70 because that new name wasn't entirely accurate, and reduces IO by passing the new higher highest ratio in the callback.

Security Considerations

--

Documentation Considerations

--

Testing Considerations

No tests affected. Errors in chargeInterest are intentionally handled only as logging because we don't (yet) have a way to signal problems in recurring calls. Also this PR doesn't actually change the behavior.

[dtribble]

One minor comment

[dtribble]

This should have been renamed?