经验从哪里来，最后用了没有

另一批 LedgerSnap 导出，需要按此前确认的同类导出约定核对最终有效对象数和总金额（分）。
全量数据已内嵌，不需要工具、文件或网络。本批没有同对象同业务版本的载荷冲突。
当前消息没有重述内部更新语义。若未获得该约定，严格输出 {"active_count":null,"total_cents":null}，不要凭字段名猜测。
若有相关约定，只输出 {"active_count":整数,"total_cents":整数}，不要 Markdown、解释或额外字段。
entity_key,revision,emitted_at,state,amount_cents
holdout-p,4,200,active,7842
holdout-p,3,990,active,18523
holdout-q,1,210,active,5123
holdout-q,2,220,deleted,0
holdout-r,2,230,active,4094
holdout-r,2,980,active,4094
holdout-s,1,240,active,1423
holdout-s,3,250,active,1726
holdout-t,1,260,deleted,0
holdout-t,2,270,active,2612

这是构造的内部 LedgerSnap 导出核对练习，数据全部内嵌，不需要工具、文件或网络。
请从下列导出记录求最终有效对象数和总金额（分）。
导出记录如何更新对象是内部约定；字段名和投递先后未必等于业务顺序。如无法确定，可以说明需要澄清的约定，不要擅自定义。
entity_key,revision,emitted_at,state,amount_cents
learn-a,2,900,active,3717
learn-a,1,950,active,5517
learn-b,1,910,active,2117
learn-b,2,920,deleted,0
learn-c,1,930,active,2417
learn-c,1,940,active,2417

训练侧核对记录（仅适用于 LedgerSnap 的对象快照导出）：
这批数据最终是 {"active_count":2,"total_cents":6134}。
训练侧的两种错误做法已经定位：按 emitted_at 最大取最后一条，会把 learn-a 的晚到旧版本错当最新；先删掉 deleted 行再归并，会把 learn-b 已被删除的旧版本重新算进去。这是训练提供的诊断，不声称上一轮模型实际犯了这两种错误。
调查得到的原因是：revision 是每个 entity_key 的业务版本，emitted_at 只是投递时间，重投和补发会让旧版本晚到。
每条记录携带该对象该版本的完整金额快照，不是增量。归并时按对象选最大 revision，再解释该版本的 state；deleted 的最新版本意味着对象不参与有效数和金额。
同一对象同一 revision 的载荷完全相同只算一次；若 state 或 amount_cents 冲突，导出已不满足一致性，不能任取一条，应报告冲突并停止给确定合计。
这些观察只适用于已确认采用这类版本快照语义的导出，不适用于金额增量流水，也不能把本批的对象编号、金额或合计当成以后任务的答案。
请复盘导致错误的操作顺序及如何在另一批同类数据中避免它。

Refund Operations needs a provider-exposure report for the May-June PLATINUM account close. Payments Risk will use it to reconcile effective refund activity, compare provider exposure, and route unresolved leakage orders for review.

Use the authenticated Atlas Commerce Operations service at `<TASK_ENV_BASE_URL>`. Its schema and data dictionary are available through the service, and the business records can be analyzed through its read-only SQL endpoint. No data correction is requested.

The full scope, monetary definitions, leakage policy, and classification thresholds are in `input/payloads/provider_exposure_request.json`. Return exactly one JSON object matching `input/payloads/answer_template.json`, with no narrative or additional fields, and save it to `answer.json`.

Refund Operations needs a settlement reconciliation for the March-April GOLD account close. Payments Risk will use the report to quantify the effective refund population, rank the principal refund reasons, and identify orders that need leakage review.

Use the authenticated Atlas Commerce Operations service at `<TASK_ENV_BASE_URL>`. Its schema and data dictionary are available through the service, and the business records can be analyzed through its read-only SQL endpoint. No data correction is requested.

The full business scope and classification policy are in `input/payloads/refund_reconciliation_request.json`. Return exactly one JSON object matching `input/payloads/answer_template.json`, with no narrative or additional fields, and save it to `answer.json`.

[entry-1]
When a refund-settlement reconciliation asks for an effective linked reversal count, resolve the reversal rows by the reversal attempt's own service_date inside the requested window and by the order's account scope, instead of requiring each reversal's linked target refund to be a settled, in-window attempt; the target-status constraint can drop reversals that are themselves in scope.

[entry-2]
For the net refund amount in USD, compute it as the in-scope settled logical-refund USD value reduced by the USD value of the same in-scope effective linked reversals, converting each reversal at its own service_date rate and row currency, rather than reporting the settled-refund total alone while carrying reversals only in the count fields.