fix(session): probe a .dat sibling for an extensionless client-absolute path

[russimicro]

What

Three lines in Connection::resolve_table_file(): in the non-legacy client_absolute
branch, probe a .dat sibling for an extensionless path, after .dbf and .adt.

} else {
    fs::path dat = cand;
    dat.replace_extension(".dat");
    if (fs::exists(dat, ec)) cand = dat;
}

Why

That branch resolves an extensionless client-absolute path by probing .dbf, then .adt,
then giving up. Legacy xBase ERPs do not follow that convention: ours keeps every table
under a literal .dat extension, ADT and DBF alike, and hands over an absolute path with
no extension at all — so those tables never resolve on this path.

This is the same ExtFile convention the project already acknowledges: #152 ("a table kept
under a non-.adt extension works end to end"), and the comment above align_type_with_file()
in this very function, which names .dat as "what the RusSoft ERP uses for every table".
This patch just extends the probe list to match what that comment already assumes.

Why it is safe

• .dat is probed last, so a real .dbf or .adt sibling still wins.
• No table type is guessed here — align_type_with_file() further down sniffs the header
  and has the last word, exactly as it does for every other extension.
• Only reachable when the client sent an absolute path with no extension at all. Anyone
  whose tables are named .dbf/.adt sees no change.

Verification

Built MSVC 2022 x64 Release on top of v1.8.78. Full unit suite: 1393/1393 passed,
538376 assertions, 0 failures — one unrelated case excluded, remote AdsCreateTable lands under server data dir and opens, which deadlocks in stock v1.8.78 too (reported
separately; it predates the multi-port commit and is not related to this change).