I don't think so. It probably came in on the original installation. I'm a bit scared to tamper with grub / boot stuff as it seems very easy to cause breakage.

Brilliant @ralph.ronnquist . That's fixed it. Thanks for the really clear instructions.

Of minor note, should others have a similar issue: it now takes a bit longer than before when logging in to connect to the network. I get a spinning cursor for about 15secs on logon (to xfce desktop) as it is detecting and connecting to the network. I'm sure that's longer than on Beowulf. So if I'm really speedy launching email / browser then it won't have acquired the connection. But I'm not complaining, just noting.

Thanks again, such a brilliant and helpful forum.

Yes, manual connection is fine.

Unfortunately no difference. No automatic connection on startup but manual forcing works fine. Out of interest, does this change how it connects or is the 'wpa_supplicant' line a convenient shorthand for what I previously had in /etc/network/interfaces?

Brilliant. Thanks. Feel free to delete this thread as noise

Hmm, I possibly fail at "citation needed". I'd read it in a number of other forums but from following those trails yesterday I can't seem to find a definitive statement that the comments originate from.

I think we've got there.

Updating the BIOS seemed to trigger at least partial recognition - the 'no codecs' message went away but ALSA didn't seem happy and no soundcards shown through 'aplay -l'. (I hadn't considered this previously as it had worked under Debian and none of the kernel release notes seem to suggest an abandon of older BIOSes.)
I also decided to switch from ASCII to Beowulf sources and do a full dist-upgrade. Although I had previously tried the Beowulf kernel (4.16) over ASCII (4.9) I thought best to get the latest versions of ALSA et al and a consistent level so that if there were any bugs or patches then I'd be in a better place to receive them.
(not needed in the end but https://ubuntuforums.org/showthread.php?t=2232882 looked useful for fault-finding similar)

I'm not sure which or all of the above was the magic, but that got me to a place where 'aplay -l' as root would detect the soundcard.
A bit more searching https://unix.stackexchange.com/question … -by-kernel revealed that my user had somehow got removed from the 'audio' group during all the fun and upgrades so 'aplay -l' as user had no soundcards. A bit of frustration that adding the user to audio didn't seem to persist for the first couple of logouts/logins but some carefully directed cursing at the computer eventually resolved that.

I'm going to give it 24 hours before marking as solved but I am happily dancing to music as I type!

I've probably installed some unnecessary firmware-* packages in the process and I'll look to carefully remove those once everything else is stable as it would be nice to have minimal 'non-free' but I'm not going to tamper with that today.

Thanks for quick response.

I've got
   firmware-linux
   firmware-linux-free
   firmware-linux-nonfree
   firmware-misc-nonfree
   firmware-realtek   [network adaptor]
   firmware-intel-sound
all installed.

modprobe snd-hda-intel

gives nothing which I think means okay(?)

but lsinitramfs only shows

lib/modules/4.9.0-6-amd64/kernel/sound
lib/modules/4.9.0-6-amd64/kernel/sound/soundcore.ko
lib/modules/4.9.0-6-amd64/kernel/sound/core
lib/modules/4.9.0-6-amd64/kernel/sound/core/seq
lib/modules/4.9.0-6-amd64/kernel/sound/core/seq/snd-seq-device.ko
lib/modules/4.9.0-6-amd64/kernel/sound/core/snd-rawmidi.ko
lib/modules/4.9.0-6-amd64/kernel/sound/core/snd.ko

when I think I should be seeing some 'snd-hda-intel' entries in there?

I guess next step is experimenting with grub boot settings (which I'm not looking forward to). Just seems odd the sound loss and codec error appeared in the Debian -> Devuan transition so I was hoping it was more a package that had got missed / incorrectly removed in that change and therefore a quick fix.