[sparkysolutions10-pixel]

Closes #130

Summary of Changes

• Hooks automatic resource cataloging into POST /settle upon successful payment settlement.
• Validates listing metadata against the Bazaar schema via submitCatalogListing without requiring any separate seller actions.
• Automatically reports cataloging acceptance/drop reasons back to sellers via the EXTENSION-RESPONSES HTTP response header.
• Fully insulated: errors or failures during catalog indexing will never delay or fail the settlement transaction.
• Keeps verify side-effect free, performing cataloging strictly on settle where payment is demonstrated.
• Tested thoroughly in src/__tests__/facilitatorSettle.test.ts.

[Miracle656]

Merged. #130 is unassigned, so this is yours.

I checked the safety of it rather than taking the comment's word, and it holds up: the block runs after the payment has been submitted, so nothing in it can change whether money moved; and submitCatalogListing already rate-limits per payTo and runs validateListing over exactly the input you hand it. So the untrusted extension body is validated — by the one function that owns that job — rather than waved through. Reusing that entry point instead of writing a second validation path is the right call and it's why this is a 22-line change.

Three things I tightened while merging

1. The catch was completely silent.

} catch {
  // Failure in cataloging must never fail or delay settlement (#130)
}

Swallowing is correct — cataloguing must never turn a successful settlement into a failed response. But with no log at all, a catalog broken for a week is only observable as listings that mysteriously never appear, which is the hardest kind of bug to notice and the hardest to diagnose once noticed. Now req.log.warn({ err, network }, ...). Swallow the failure, not the evidence.

2. The comment overclaimed. It said cataloguing cannot "fail or delay settlement". The first half is true; the second isn't — the call is awaited, so it does delay the response. It also has to be awaited, because the result goes back in the EXTENSION-RESPONSES header and you cannot tell a caller which fields were dropped after the response has already gone. So I kept the await and corrected the comment instead: the payment is already submitted, the only cost is response latency. Worth being precise about, because the next person reading "cannot delay settlement" might move the call off the request path and silently lose the header.

3. bazaarExtension as any → RegisterBazaarResourceInput from src/bazaar/types, with a comment noting the shape is deliberately not re-checked here because submitCatalogListing validates it. Same behaviour, but now the reason the cast is safe is written down rather than needing to be rediscovered.

I also documented why both extensions.bazaar and a flattened discovery key are accepted — that dual shape is the kind of thing that looks like an accident six months later.

Verified on the merge result rather than your branch: tsc --noEmit silent, 887 tests across 82 suites, nothing red.

Correction to what I said on #532

I told you there to land #532 first and rebase this onto it. That was right when both looked close, but #532 now needs real rework — the spend ceiling reads a caller-supplied amount instead of the signed XDR, and the allow-list can be satisfied with an Origin header — so holding this behind it would have been for nothing. This went first instead. #532 will need a rebase onto current main; src/routes/facilitator.ts and facilitatorSettle.test.ts both moved.

Closes #130.