docs: verify raw Oracle room type evidence for PM records

.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md

@@ -249,3 +249,9 @@ Read: memory-index, project-positioning, current-state latest September sections
 - Replayed only in-memory parsing/classification/pricing, with no artifact generation, database/Finance access or Oracle reads: original9/16 XML under both pre-interface5ecd571 and current code yields184 source rows,150 valid candidates,34 rate exclusions,0 duplicates,0 classification errors,35 PRICE_UNMATCHED and exactly1 price group LIAN TAI/WHO2/1000. Current saved OHIP source yields209 rows,160 valid candidates,43 rate exclusions,6 cancellation exclusions,45 PRICE_UNMATCHED and5 groups. The common184 reservations have identical rate/Opera amount/nights/rooms/outcomes/processed amounts/totals; all150 actionable rows have identical normalized company keys too.5 company-key differences occur only on records already rate-excluded by both inputs; this is not a claim of full text equivalence. Original XML/source bytes remain unchanged.
 - Concrete additional source evidence: the25 API-only reservations comprise6 excluded cancellations,9 excluded rates and10 price-unmatched candidates. All10 unmatched extras have ROOM_CATEGORY_LABEL=PM, adults0/children0, Opera amount0, CheckedOut status and rooms9002/9004/9005/9006/9007/9035/9044/9045/9048/9052. None is in the XML. Official Oracle Cloud [room-type configuration](https://docs.oracle.com/en/industries/hospitality/opera-cloud/25.1/ocsuh/t_rooms_managing_room_types.htm) identifies provisioned PM as a non-inventory pseudo type; [OHIP prerequisites](https://docs.oracle.com/en/industries/hospitality/integration-platform/pcpig/c_prerequisites.htm) explains posting-account codes are customer-definable and recommends verifying the customer's configuration. This supports a specific pseudo-room scope hypothesis rather than blaming generic0 validation. It does not prove this hotel's saved RES_DETAIL pseudo-room predicate or authorize filtering by room-number prefix or blanket code-only classification.
 - Outcome: original pricing rules/reference are preserved and the same XML produces the same original review item. The extra4 price groups originate from10 additional PM source records. Do not ask staff to solve source-population mismatch solely by entering prices. No code change, test suite, live service/config changes, actual price decisions or report generation occurred. Follow-up/promotion: establish the original report's pseudo-room inclusion criterion and align acquisition/adapter eligibility with it while keeping shared pricing intact; preserve immutable original capture and audit any scope interpretation. Do not infer universal CheckedOut-only or PM-only filtering from this sample.
+
+## Same-task Follow-up: Evidence for the PM Label
+
+- User asks how PM was identified and what characteristics support it. Same-task ownership/feature/codex/base2417b1a/owned checkout/no peers and retained Project Context Loaded verified; Planning gate Passed for read-only source-evidence inspection. No new source request, report/rule change or hotel configuration assumption is authorized by this question.
+- Reopened the saved original search/detail responses for all10 API0 price-unmatched rows. In every row search.roomStay.roomType, detail.roomStay.currentRoomInfo.roomType and detail.roomStay.roomRates[the9/16day].roomType explicitly equal PM. This is the same3-way agreement used by source_fields.agreed_room_type, not an inference from room-number prefix, zero amount or roomTypeCharged. Two examples: confirmation300638606/room9002 and300638238/room9004, all3 PM fields agree; both also have amount0 and adults0/children0. These latter features are auxiliary, never a standalone pseudo-room rule.
+- Broader source count23 PM records (19 CheckedOut,4 Cancelled) should not be confused with the10 actionable unmatched PM records discussed here. Nothing establishes that PM is the only pseudo code in this hotel, or that every9xxx room/0-price reservation is pseudo. The official Oracle default-PM meaning remains supported by the links above, while actual report eligibility still requires the original report criterion. No code/data/price edits, Oracle calls, test suite, service action or actual generation occurred. Explain explicit roomType evidence separately from the not-yet-settled decision to exclude it from the report.