Fix: TypeError when Message::make() is called after an implicit reconnect

[k00ni]

Disclaimer: This fix is similar to #615 from @braito4 but with slightly different changes.

---

We had the following error in our logs recently:

In Message.php line 1473:
Cannot assign null to property Webklex\PHPIMAP\Message::$folder_path of type string

🤖 Because I am not familiar with the IMAP specification I asked Claude Code to analyze the problem and provide me a solution. It came up with a minimal set of changes. I checked them manually.

---

Problem

When the IMAP connection drops during a message fetch and the library reconnects internally, Message::make() throws a fatal TypeError:

Cannot assign null to property Webklex\PHPIMAP\Message::$folder_path of type string

Client::connect() always calls disconnect() first. disconnect() resets active_folder to null. When getConnection() triggers an implicit reconnect mid-fetch (e.g. inside Query::fetch()), active_folder is null by the time Message::make() runs. make() then passes null to setFolderPath(), which PHP 8 rejects because $folder_path is declared as string.

Fix

Two changes, each addressing a different layer of the problem:

1. Client::checkConnection() — root cause fix
Save active_folder before reconnecting and reopen it afterwards, so the selected mailbox is never lost across a reconnect.

2. Message.php — type safety + reliable fallback

• setFolderPath() accepts ?string instead of an untyped parameter, which eliminates the TypeError.
• In make(), setClient() is moved before setFolderPath() so that the client-based fallback inside setFolderPath() can actually reach $this->client->getFolderPath(). Without this reordering the fallback is dead code and every unresolvable folder silently defaults to 'INBOX'.

Tests

Two tests were provided to show the problem and demonstrate that the fix works.