Currently, an LN node backed by a Bitcoin full node definitely will watch the chain and remove channels when their output is spent. Light clients can’t effectively do this, and as roasbeef mentions fall back to using the channel_updates as a liveness signal (or use some trusted source for graph/routing information).
Exactly. A channel being unspent on-chain is no guarantee that it is still usable, so it is nice to get some kind of heartbeat from the nodes. This is why I think requiring a refreshed channel_announcement every few weeks is not a bad option.
I definitely think that would be a big loss, since closing channels then will be discouraged since it hurts privacy.
In my current implementation, I prove in ZK that the advertised capacity is less or equal to the on-chain output. This leaves some obfuscation to what (taproot) outputs it could be. In a production implementation I would imagine a floating range could work, as roasbeef suggests.
It is worth mentioning that there’s no way to tell whether the channel was open or not before the checkpoint. So a privacy conscious node could open the channel on-chain, but wait several weeks before announcing it (they could actually start using it as a private channel right away, then later make it public).