It's complicated.
ARM system initialization doesn't happen the same way as on x86 (the instruction set your computer is probably using unless you're on a phone/tablet). On x86, once the CPU is initialized, it can inform the Linux kernel of what hardware is installed and how to talk to it through a protocol called ACPI. Thus, for Linux to work on a system, it must only support the CPU and some necessary hardware (e.g. I doubt you'll have a usable system if USB, graphics, audio, and networking are unsupported, but otherwise it's fine).
ARM functions quite differently; ACPI doesn't exist ACPI is also usable on ARM but Qualcomm refuses to implement it, so instead the Linux kernel has to already know what hardware is installed and where through a configuration file called a device tree blob - basically weird JSON. Therefore it's not enough that Linux supports the Snapdragon 7c (it does) - there must also be a builtin device tree config for your specific device. There likely is one; a simple way to check would be to look here for your device's name (the Snapdragon 7c's codename is SC7180, so the file you're looking for would be sc7180-$vendor-$model.dts). If there isn't and you're willing to get moderately deep in the weeds, you can write your own device tree source file and load it into the kernel (assuming you have at least a rudimentary familiarity with programming, this is doable with a little dedication).
As for your other questions, you don't need to worry too much about instruction set and architecture - being ARM will limit what software can run, but emulation is sort of okay too. It will, however, be far more power-efficient than a 6th gen Intel i3 if that's what you care about - and gut instinct says faster.
It really depends on your usecase, though. If your budget is limited enough that these are serious options, I'd honestly recommend finding a decent second-hand laptop running something a bit better and more recent - but if you run mostly open-source software, don't care about gaming at all, and are willing to get a little deeper than the average hobbyist for some extra battery life, the ARM laptop might be interesting.
There's a lot of reasons people hate on Manjaro, though generally they boil down to instability - despite being on a slower schedule than Arch, a lot of people report worse breakage; their main "testing" is just being a week behind Arch without actually testing much.
Crucially, this can break things when mixing in AUR packages since those are shared w/ Arch and so anything in there that's precompiled against the Arch version of relevant libraries might just break.
It also has considerably deficient security policies, such as the GUI installer
pamacallowing unsuspecting users to trivially install unvetted packages from the AUR without even a clear indication they may be dangerous, and they forgot to update their SSL certificatestwiceedit: five times (see https://lemmy.ml/comment/1343440), asking users to manually overwrite them as a "fix".Unrelated to desktop, I've also noticed Manjaro staff are quite hostile and unpleasant to work with; I'm involved in a project that works on Linux on mobile devices, and Manjaro's mobile team has been less than the most pleasant. This is a personal gripe for sure and unrelated to the distro itself, but if I'm going to take a dump on Manjaro I'll do it all the way.
As for your other question; you can simply copy the sway config file from the Manjaro install. Either mount the ISO and search there, or if it needs to be installed to populate the sway config, just install in a VM and copy it from there. Necessary packages should be relatively easy to find by just reading the errors sway spits out and googling them.