WeKan-11.48-win64.exe died on every start, restarted, and died again:

...\accounts-password\node_modules\bcrypt\promises.js:1
MZ......  !.L.!This program cannot be run in DOS mode.
SyntaxError: Invalid or unexpected token
    at Object.<anonymous> (...\bcrypt\bcrypt.js:6:18)

Both published files were correct. wekan-11.48-win64.zip holds the real
1123-byte promises.js, and so did the EXE: in its packed image
bcrypt.node (195584 bytes) is entry 0x5c9c and promises.js is
0x5c9d, stored back to back, each with the right bytes at the offset its
own record gives. What was wrong was the READ. Enigma Virtual Box served
all 44,401 bundle files from a virtual filesystem inside the EXE, and once
Node.js had loaded the native addon out of it (bcrypt.js line 2), the
next read - require('./promises') on line 6, the blob immediately after
that addon - came back as the addon's own PE bytes.

So that packer is gone. The EXE is now the compiled launcher with the
published ZIP appended to it and an 80-byte trailer saying where that
payload starts, how long it is, its SHA-256 and which WeKan it is. The
download drops from 690 MB to about 232 MB, because the payload is the
compressed ZIP rather than an uncompressed image, and a damaged copy - a
truncated download, a half-written file - now stops at the checksum with
the expected and actual hashes and a line saying to download it again,
instead of reaching Node.js as a crash loop.

Its release smoke test is why a broken EXE was published at all.
start-wekan.bat restarts WeKan every three seconds when it exits, and the
smoke test polled http://localhost:8080/sign-in for three minutes: an EXE
that crashed on nine starts out of ten still answered inside that window,
and the job went green. It now starts the EXE twice - the run that unpacks
and the run that must find its files already there - and fails if either
log contains WeKan exited; restarting or SyntaxError. It also no longer
trips over PowerShell's read-only $pid while freeing the ports FerretDB
needs.

tests/windowsSingleExe.test.cjs pins the trailer format from both ends -
every TRAILER_* the launcher defines must equal the constant
releases/append-windows-payload.mjs exports under that name - round-trips
a packed file through pack and verify, and requires a flipped byte, a
truncated payload, a missing trailer and an over-long version to be
refused. A negative test reads every file under .github/workflows and
releases and fails on any Enigma Virtual Box download, console or .evb
project, so that virtual filesystem cannot come back through a second
packing path.

Replacing the packer left the EXE writing its whole bundle - 39,035 files,
685 MB - beside itself on the first run. It does not any more.

Only what cannot be virtual is unpacked, and the reason is the same in
every case: something other than WeKan's own module loader has to open it.
node.exe and ferretdb.exe are separate processes, so Windows needs a
real path to start one; .node addons are loaded with LoadLibrary, same
reason; main.js is the entry Node resolves before any hook could see it;
start-wekan.bat is read by cmd.exe; and wekan-vfs.cjs is read by
node --require before anything is mounted. main.js also chdir()s into
programs/server, and a working directory is a kernel concept no hook can
answer, so that one directory is created for real. That is about thirty
files out of 39,035, and the list is computed from the archive rather than
written by hand, so a bundle that gains an addon or a database tool cannot
silently lose it.

The mount is releases/single-exe/wekan-vfs.cjs, and it needs two
mechanisms because Node needs both. module.registerHooks() answers
require: the CJS loader resolves through internal C++ bindings, so
patching fs cannot make require see a virtual file, and Module._stat
is captured as a module-local inside Module._findPath, so replacing it
does nothing either. Resolution is therefore reimplemented, and checked
against Node's own answer for every package in a real bundle - 1407 package
directories and 1865 bare specifiers, all matching. fs patching covers
everything that is not a module: Meteor's boot.js reads program.json
and every server package with fs.readFileSync and runs them through
vm.runInThisContext, and webapp serves the client files with
fs.createReadStream. Below both sits one more: Meteor's runtime.js
hands reify a resolver that calls Module._resolveFilename directly, which
registerHooks never sees.

Two traps are worth naming because both were hit here. A .node addon must
be resolved with NO format declared - saying commonjs for one makes Node
compile the binary as JavaScript and die with SyntaxError: Invalid or
unexpected token on its own header, which is the 11.48 crash reproduced
from the other side. And a directory that exists both really and in the
archive has to merge the two listings, or wekan-app/programs/server would
list the two unpacked files and hide the entire server.

This was verified by running it, not by reading it. With 23 real files on
disk and 38,931 served from the ZIP, WeKan boots, connects to FerretDB and
answers 200 on /sign-in and on its 6.9 MB client bundle.
tests/bundleArchiveVfs.test.cjs builds a small archive and pins the three
things that have to stay right - the ZIP reader, the resolution and the
declared format - including the two traps above, and the release smoke test
now counts what reached the disk, so a change that quietly went back to
unpacking everything fails the job instead of passing it.

bcrypt and argon2 (Meteor's accounts-password) each ship one
prebuilds/<platform>-<arch>/ directory per platform they support: 21
native binaries in every WeKan bundle, of which exactly one is ever opened.
Their loader is node-gyp-build, and its resolve() reads a single
directory - readdirSync('prebuilds'), filtered by matchTuple(platform, arch) with platform and arch from os.platform() and os.arch().

That is the same argument releases/bundle-trim.mjs already makes about
uWebSockets.js, so it is the same code path. --trim-prebuilds keeps the
directories node-gyp-build would match and drops the rest, using that
loader's own tuple parsing - multi-arch names such as darwin-x64+arm64
included - and keeps both libc flavours of the target, because glibc versus
musl is decided at runtime and not here.

Three things make it safe rather than merely smaller. It is off by default
and refuses to run without an explicit --platform and --arch, since the
defaults are linux/x64 and a Windows or macOS bundle trimmed with those
would lose the only addon it can load - the fault the single EXE was just
fixed for. build-amd64 deliberately does not pass it, because every other
bundle WeKan ships is that bundle repacked and trimming there would take
the prebuilds away from architectures not yet built; each final
per-platform job passes its own target. And every decision is made before
anything is deleted, so a package whose prebuilds cannot be reasoned about
is left whole rather than half-trimmed - which is how bare-fs,
bare-path and bare-url were found, shipping prebuilds/ of .bare
files for the Bare runtime. Those are left untouched, and say so.

On the mac-arm64 bundle 19 of the 21 go and the two for darwin-arm64
stay. For the single Windows EXE it takes the files that have to be
unpacked from 33 down to about fifteen.

Moving a list to another swimlane on the same board did nothing at all. The
list kept its empty swimlaneId, so it went on rendering under every
swimlane, and deleting "the one in the second swimlane" deleted the only
list document there was. A board backup showed the empty swimlaneId on
lists that the report describes.

List.move(boardId, swimlaneId) asked does the target board already have
a list with this name? without first asking whether the target board IS
this list's board:

const boardList = await ReactiveCache.getList({
  boardId, title: this.title, archived: false });
if (boardList) { ...merge, never writes a swimlaneId... }
else           { ...insert a new list WITH the swimlaneId... }

On a same-board move that search finds THIS LIST, so the merge branch ran -
and the merge branch is the one branch that never writes a swimlaneId.
The chosen swimlane was discarded every time, which is also why the binding
could not be put back by hand.

Merging is only meaningful across boards; on the same board a move is a
re-bind, and that is what it does now. The decision lives in
models/lib/listMovePlan.js, where it is unit-tested, and models/lists.js
applies it: same board re-binds this list, another board with the name
already taken merges the cards into that list, another board creates it
there and binds it. An empty swimlaneId remains a deliberate un-bind back
to board-wide, which is still a legitimate layout, and moveList now
refuses a swimlane that is not on the board the list is moving to.

The same branch also called card.move(boardId, this._id, boardList._id).
Card.move's second argument is a swimlaneId, so this set every card's
swimlaneId to a LIST id - a swimlane that does not exist - and those cards
became the orphaned cards the board-open repair has to rescue. The cards
were selected as this.cards(swimlaneId) as well, filtering the SOURCE
list's cards by a swimlaneId belonging to the TARGET board, which on a
cross-board move matches nothing and left every card behind. Both are gone:
a list's own cards travel with it, into the chosen swimlane. A negative test
scans models/lists.js for any card.move() whose second argument is not a
swimlane, so the argument order cannot go wrong at another call site.

This does not restore bindings already lost. Boards opened under the
versions before #6515 had
every list un-bound automatically, and which swimlane each list belonged to
is not recoverable from the data - a list's cards can be spread across
several swimlanes, and on a board whose second swimlane is new they are all
in the first, so guessing would bind every list to one swimlane and hide it
from the others. With this fix the binding can at least be set again from
Move List.