* preserve-parent:
  Preserve previous parent id when re-activating plan

* show-remaining-included-calling-credit:
  Show remaining included calling credit in customer info
  Add missing require

* ruby3:
  Fix for ruby3
  Test on Ubuntu LTS (with ruby3)
  Update to new minitest

* longer-auto-top-up-block:
  The secondary block should be longer than the main lock...

* customer_id_in_order:
  Include customer id as CustomerOrderId when ordering number

So we can tell who ordered a number in case of issues

* prev:
  Allow prev from mail-in registration
  Allow prev from invite code
  Allow prev from credit card form
  Make sure OOB comes first in payload
  Allow prev from Bitcoin registration
  Allow prev action on TelSelections search results

* disable-voicemail:
  Allow infinite timeout / disabled voicemail

Use Forward to hand control completely to the target call.  If something ends up
at our voicemail due to error or similar, just hang up.

* tel-in-ogm:
  Switch default OGM to include tel

We transform the keys into symbols, but then index with a string.

* no-15-spin:
  Auto top up enough to get to auto_top_up_amount
  Remove Customer knowledge of all presenter objects

If auto top up amount would not get us to $5 (because of very negative balance),
we don't want to loop multiple auto top ups, so instead just do one larger one
to get to auto_top_up_amount

for any auto top up

In case language_id guessed wrong

* multi-account-billing:
  Use billing customer for LowBalance notification
  Get settled amount from billing customer for TrustLevelRepo
  Use the multi account billing schema

* voicemail-on-error:
  Use default OGM when error loading customer
  On customer load error, try not loading from SGX and assuming no transcription

* admin-actions:
  Admin Command Flash
  AddInvites Command
  SetTrustLevel Command
  ResetDeclines Command
  Undo and Undoable Command Harness
  Move Cancel and Financial Admin Commands
  AdminAction and AdminActionRepo
  Invites Repo
  Cleanup Admin Form

Having a second response here just to show the result, and then have to
skip by it to get back to the menu is dumb.

So instead we just added a thing here so we can tag some info to show up
on the next form, and then go to it.

Much smoother, but it does depend on a change in the adhoc bot which
previously didn't show notes when there was also a form.

This one adds a certain number of invites to a user, and then records
which ones were added so they can be removed in the undo case.

Here we have a form for the extra information we need. They say they
want to set the trust level, we ask which one they'd like, and then we
make the command that does that.

This involves adding a new method to the TrustLevel to get just the
manual level, so I can tell the difference between being set to Customer
manually (in the form) or being automatically determined to be Customer
(which means the form should be set to automatic).

I also obviously need the method to set a new trust level too.

This is a nice simple first one.
I set the declines to 0, and on Undo I set it back to what it was
before.

There's no extra form or information, it just does the thing.

It's a little weird to start with Undo when there's nothing to Undo yet,
but it's laying the groundwork for what's to come.

This gives me a harness I can use here that gets the action, performs
it, gets the result of that performed action, and then persists that to
the log and reports success or failure.

And the first such action I have just grabs the most recent item and
undoes it.

This class gets pretty tight later, so I have to move these out to make
room in the class for the other commands.

This Simple class is a bit weird on its own here, but it makes a bit
more sense later when compared to another class.

This allows me to enqueue a description of a change to a stream and then
run it. And then later find / list them and undo any of them.

The goal here is to make these safe to run and safe to reverse so the
user can just run things with confidence knowing that undo's always got
their back.

This allows me to avoid confirmation boxes on everything and careful
scrutinizing of each command before it's run just in case...

In preparation for another command I'd like to make I've first got to
make a place where Invites live.

There's probably other parts of the code that interact with Invites that
I've missed, but this is a good start at least.

It used to handle the initial failure differently than internal failure.
Now I've moved the outside bits inside, so it can run again when it
encounters an unknown character.