fix(process): refuse to start a second session process for one id

[xepozz]

Found while tracing why a channel conversation was not appearing live in a Kickside UI. Not the cause of that, but a real race on the way.

The defect

src/process/session.lua claims the session name and throws the answer away:

process.registry.register("session." .. args.session_id)

process.registry.register reports whether the name was already taken. Discarding that means two spawns for one session id both proceed. Each opens its own writer, both append to the same conversation, and the process that lost the registration keeps serving a name that no longer routes to it — so everything it sends upstream goes nowhere, silently.

Why the caller cannot fix it

src/process/plugin.lua checks only its own in-memory map before spawning. A second caller — another plugin instance, a channel bridge, or any ensure-then-spawn path — has no way to observe the first. The registered name is the only authority, and this line is already claiming it.

The change

Ten lines: keep the result, and fail the start when the name is taken. That matches how the surrounding code already treats a session it cannot open (Failed to open session, Cannot open failed session).

Verification

make lint reports the same 22 pre-existing errors and 1 warning before and after the change, none of them in wippy.session.process:session. I could not run make test locally — the harness stops at failed to expand changeset: verified dependency evidence is unavailable during offline startup — so CI is the first real run.

Happy to add a regression test if you can point me at how to spawn two processes for one id inside the harness; nothing under test/ currently exercises the session process directly.