After reading through Eclectic Light posts + comparing setup methods on Intel + Apple silicon, the reason for connecting to Apple servers is due to what Apple calls "personalization", where the signatures of SSV partition files are checked with Apple. (It seems like the personalization servers will decline to verify any but the the latest releases of macOS, but that doesn't change the need to contact the servers.)

So, the only ways to install a SSV [1] are 1) through the macOS installer, and 2) using the asr command line tool (macOS 11.1's asr seems to be broken, so this is only true in 11.2 or 12+). asr is Apple-proprietary, and mostly supports copying images to/from existing SSV's (which seem to be architecture-specific).

• This means I can back up a recent Mac + its System volume to an external drive, and also restore it offline, but
• updating requires you to run the macOS installer somewhere, which will then try to hit the personalization servers.
• And restoring across architectures (Intel => Apple silicon) just doesn't have the right SSV, so you'll need to find a matching SSV/backup, or run the macOS installer again.
  Firmware updates are also excluded from this process, so you'll be forced to run the macOS installer in those cases.

There are ways to construct a custom macOS image (manually bless-ing your modified System volume), but they require disabling SIP + SSV (which is what OCLP does), which can be unacceptable depending on your threat model.
(Note that since SSV works with volume snapshots, you can always roll back your SSV to the Apple-signed version, so this feels like less of a concern.)

For future reference, here's how I constructed a completely offline backup + restore for an Intel Mac (2019 MBP (with T2 chip), macOS Sonoma 14.2.1):

# first, reboot into macOS recovery (probably not necessary, but it's where I got things to work)

# manually create a r/w disk image to hold the... image
hdiutil create -fs apfs -size 80g -type sparsebundle -attach test4

# look for the `/Macintosh HD` disk in `diskutil list`: disk5s2
diskutil mount readOnly /dev/disk5s2
diskutil apfs listSnapshots /dev/disk5s2

asr --source /dev/disk5 --target /dev/disk7 -toSnapshot AAAAA-GUID

The -toSnapshot is important, as it selects the SSV snapshot that gets preserved. This leaves you with a disk image that we can turn into a restoreable backup.

And to restore:

# Note that `asr` will re-order data on the source disk,
# so if you converted to a read-only image, you'll need to `hdiutil -shadow` to make it writeable.
hdiutil convert -format UDRO -o test4-singlefile test4.sparsebundle

# `asr imagescan` seems to pre-compute this re-ordering, but I haven't re-run this process to reconfirm
#
# Note that you can also use `FULL_USAGE=1 asr` to get more detailed asr usages,
# https://derflounder.wordpress.com/2013/04/30/asrs-hidden-documentation/
#
asr imagescan --source test4-singlefile.dmg --filechecksum --verbose

hdiutil mount test4-singlefile.dmg -noverify -shadow test4-shadow
asr restore --source /dev/disk8 --target /dev/disk4 --toSnapshot AAAAA-GUID --noverify

Notes:

• asr works on entire APFS Containers, individual volumes cannot be split out (man asr talks about the necessity of the Preboot and Recovery partitions)
• I left off all the image verification steps because they take a long time + I was running these commands many times (-noverify and --noverify).
• This whole thing is simpler with an external drive, but I'm using files for thoroughness.