I do not manage to reproduce no matter which language settings I choose, but an easy reproducer is replacing
'd' => "{$start_year}-{$start_month}-{$start_day}"
in https://we.phorge.it/source/phorge/browse/master/src/applications/calendar/query/PhabricatorCalendarEventSearchEngine.php$539 with a bogus value like
'd' => "2024-0A-696"

PhabricatorCalendarEventSearchEngine::buildCalendarMonthView has the line $from = $this->getQueryDateFrom($query)->getDateTime();.
AphrontFormDateControlValue::getDateTime() calls AphrontFormDateControlValue::newDateTime(). Here, $datetime = new DateTime("{$date} {$time}", $zone); fails for unknown reasons, so the methods returns null when catching an exception.

Note that the three existing if (!$datetime) checks in https://we.phorge.it/source/phorge/browse/master/src/view/form/control/AphrontFormDateControlValue.php imply that this can be null.

There are two options to deal with this:

One is to continue ignore that DateTime should not be null, as catch (Exception $ex) { return null; } code in AphrontFormDateControlValue already does, and introduce some fallback code in PhabricatorCalendarEventSearchEngine to handle it being null:

     $from = $this->getQueryDateFrom($query)->getDateTime();
+    if (!$from) {
+    // Hide exception and render current month everywhere, no matter what
+      $from = $this->getSafeDate($from)->getDateTime(); //
+    }

Other option is to stop ignoring exceptions in AphrontFormDateControlValue and throw them instead:

       $datetime->setTimezone($zone);
+    } catch (DateMalformedStringException $ex) { // PHP >= 8.3.0
+      throw new DateMalformedStringException($ex->getMessage());
     } catch (Exception $ex) {
-      return null;
+      throw new Exception($ex->getMessage());
     }
     return $datetime;

Docs upstream part (unrelated to a bug fix): https://we.phorge.it/D25793

Added debug output in https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/commit/5679ff7c5e6c3b421bcf2e7f7c82d74a61b85278

Debug output has fun values: o2wln, xz7lx, hc6j5.
According to access logs, that's just folks fuzzing by accessing bogus URIs like
http://phabricator.wikimedia.org/calendar/?__path__=%2fcalendar%2f&categoryid=ud5ph&email=hbzr5&enddate=dzgh3&invitedPHIDs=zq1g4&item=xkq1i&jsonp=yv5jo&key=dxqnv&mod=bqwz6&p=sc4l1&page_id=csgzg&projectPHIDs=w0184&projectPHIDs%5B%5D=hd0kc&query=py5b5&rangeStart_t=bfl1k&search%3Aapplication=k5l3d&search%3Aprimary=bmfnz&search%3Ascope=w8hmg&token=ez9tk&type=b74da&uid=ppy2d
or
http://phabricator.wikimedia.org/calendar/?__path__=%2fcalendar%2f&__csrf__=a066z&api=xwjvy&invitedPHIDs=p8nt0&l=fk97j&projectPHIDs%5B%5D=j28o7&q=rjeqa&subscriberPHIDs=gimtk
but still not sure how that exactly ends up with such an invalid DateTime value.

Boy oh boy... After reading this piece of code to understand it better, I realize how easy this is to trigger:
Check "Occurs After" in the advanced search in calendar month view on http://phorge.localhost/calendar/query/advanced/ , enter an invalid date or time abcde, click Search. Same applies for buildCalendarDayView() in the line $month_uri = $browse_uri.$from->format('Y/m/');
I'll cook up an upstream patch to validate values and throw an exception.