Fix/max path id eager stock setup

[mirjak]

Resolves the design question we deferred earlier — initial_max_path_id/MAX_PATH_ID are both peer-controlled values already bounded by our own max_path_id, so a mid-connection increase shouldn't be treated any more cautiously than the handshake-time case, which already eagerly creates stock paths via _setup_paths_in_stock().

Both directions of "max_path_id rising" now trigger eager stock setup, matching the handshake-time behavior:

• _handle_max_path_id_frame — when the peer raises the limit via a MAX_PATH_ID frame (only for genuinely increasing values, non-increasing ones are correctly ignored per the draft).
• raise_max_path_id — when we raise our own limit locally; this can unblock stock paths for path IDs the peer already permitted even if the peer's own limit never changed, since the effective ceiling is min(self._max_path_id, self._remote_max_path_id).

Both are guarded by if self._multipath_negotiated:, matching the existing convention at the two pre-existing _setup_paths_in_stock() call sites, and both reuse _setup_paths_in_stock()'s own idempotency (it skips any path ID already present in either dict), so calling it repeatedly is safe.

4 new tests covering both directions' eager-creation and non-increasing-value-is-a-no-op cases, confirming both that the right path IDs get created and that each new stock entry already has its own host_cids populated (ready to send a CID for that path). Zero regressions (143 tests, same 18 pre-existing failures/errors).