Fix DBENGINE PGC races in pgc_page_add and pgc_queue_del (#22466)

* fix(dbengine): clamp pgc_page_add timestamps before initializing the page allocation->start_time_s was written from entry->start_time_s before the negative-value clamps ran, so a negative entry would leave the PGC_PAGE struct holding the original value while the Judy index was keyed at the clamped 0. remove_this_page_from_index_unsafe would then miss by page->start_time_s and trip the cache.c:1041 fatal. Move the clamps to just after the internal_fatal so the struct and the index key are built from the same value. Same change applied to end_time_s for consistency. * fix(dbengine): clear pgc_queue_del flag after the unlink pgc_queue_del cleared the queue flag before unlinking the page from the queue's linked list. Under the queue lock this was harmless to other holders of the same lock, but the flag is also read lockless-ly by readers that then take the queue lock and walk link.prev / link.next. A reader observing "no longer on this queue" between the flag clear and the unlink could still find the page on the list and corrupt the in-progress unlink. Move page_flag_clear after the linked-list unlink (and the sections-judy delete in the linked_list_in_sections_judy branch), keeping the same lock window. Same re-validation pattern as #21793 applied to the writer side. * docs(dbengine): clarify pgc_queue_del and pgc_page_add comments - pgc_queue_del: the guarantee is "flag-cleared implies already unlinked", not the reciprocal; reworded to state the actual invariant and reference the re-validation pattern readers must use. - pgc_page_add: the internal_fatal above is itself a read of these fields; the clamp protects the PGC_PAGE struct and the Judy index key specifically.