Today transaction throughput on the Lightning Network is mostly limited by available liquidity, network topology and direction of payments. It is possible longer term if Lightning becomes widely adopted that block size/weight and onchain transaction fees will add an additional constraint as you do need an onchain transaction to open or close a channel. However, today blocks mostly contain single signature transactions rather than Lightning channel opens and closes and so that constraint isn't being hit today.
To briefly explain liquidity, network topology and direction of payments. If you want to route a 10,000 BTC payment on Lightning you are going to struggle because there isn't sufficient capacity in channels to route such a large payment. If you want to make a payment to a very poorly connected Lightning node at the edge of the network you may struggle to find a route to that destination. And if all Lightning payments are being sent in one direction and Lightning channels become highly unbalanced then you may encounter a lot of routing failures if you try to make a payment that is also going in that same direction. All of these can be addressed using onchain transactions to open more channels, add more capacity to channels or rebalance channels but could pose difficulties in the short term.
My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup).
Every new channel needs a single onchain transaction sending Bitcoin to a 2-of-2 multisig address.
So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?
Yes, block space provides an upper limit on how many channels can be opened and closed but that limit is not close to being hit at the time of writing (September 2022). Once channels are opened the transaction throughput is theoretically infinite. For example we could send a payment back and forth in a channel an infinite number of times and technically that would be an infinite number of transactions. In practice you wouldn't want to do that but other variables come into play (liquidity, network topology, direction of payments etc) other than merely block space.
Perhaps that allows key holders within the app to somehow nominate channel operators to act on their behalf?
There are different models for delegating responsibility either in trusted setups or more trust minimized setups. Obviously you could pay to use a channel operated by a company rather than opening your own channel but that is entirely trusted. If you want your own channel and not to have to trust a third party you can't get around the requirement for an onchain transaction. Longer term there are proposals for channel factories etc where a single UTXO is backing multiple channels but they are not spec'ed and implemented at the time of writing (September 2022).
