Do not empty a sessions table the site may not have

The load harness's reset empties three tables, and one of them may not be there. yoyaku:load-clear --truncate truncates sessions unconditionally, so on a site that keeps its sessions anywhere other than the database the command dies with "Base table or view not found", and takes the run with it: the reset is the first thing every arm does, so nothing is measured at all.

Found by running the harness against a freshly installed rig that had no sessions table. The failure is loud, which is the one good thing about it, but it is also total.

The fix

Ask whether the table is there before emptying it. The bookings and the baskets are this module's own and are always present; sessions belongs to core's session handling and is a reasonable thing for a site not to have.

Worth keeping the truncate rather than dropping it. A run leaves one session per visitor, tens of thousands of rows, and the next arm reads them; clearing them is why the reset is there.

Test coverage is the awkward part and I would rather say so than pretend: the branch a test would need is "the table does not exist", which a kernel test installs by default. Making it absent to prove the guard would mean dropping a core table underneath a running site, which teaches nothing about this module. The guard is one condition and reads as its own proof, so this ships without a test rather than with a contrived one.

Introduced by #3615593: Load test the booking path: what it bears, and what gives way first.

AI-Generated: Yes (Claude Code wrote the code this fixes and this issue summary, and hit the failure while running the harness rather than by reading it.)