feat(ai): add RxJS-native AWS Comprehend PII redaction

[lasder-ca]

feat(ai): add RxJS-native AWS Comprehend PII redaction

/claim #290

I have read the Arakoo CLA Document and I hereby sign the CLA.

Summary

This adds ComprehendPiiRedactor to the JavaScript AI package so prompts and chat messages can be redacted before reaching an endpoint.

The implementation includes:

• Amazon Comprehend DetectPiiEntities integration using the standard AWS SDK credential chain
• a real RxJS OperatorFunction, implemented with ordered asynchronous processing
• an endpointOperator() for chaining redaction directly into existing chat()-style endpoints
• redact$(), redactChatOptions$(), and wrapEndpoint() helpers
• cancellation forwarding through AbortSignal
• Unicode code-point-safe replacement for emoji and other supplementary characters
• confidence and entity-type filtering
• deterministic overlap handling
• explicit 100 KiB UTF-8 input validation
• immutable prompt/message transformation

Why this is different from existing attempts

Several existing submissions expose a Promise-returning function as an “operator” or manually subscribe with an async next callback. This patch uses an actual RxJS OperatorFunction, preserves source ordering, waits for each Comprehend request before completion, propagates errors normally, and aborts an in-flight AWS request when the subscription is cancelled.

Example

The new JS/edgechains/examples/aws-comprehend-redaction example runs offline by default with a deterministic client:

Original: 🔒 Please contact jane@example.com or call 555-010-1234.
Endpoint received: 🔒 Please contact [EMAIL] or call [PHONE].

Set USE_REAL_AWS=true to use Amazon Comprehend with the normal AWS credential provider chain.

Verification

Focused validation completed:

npx tsc --noEmit
npx vitest run src/ai/src/tests/comprehend/comprehendPiiRedactor.test.ts

Result: 9 tests passed.

The standalone example also type-checks, builds, and runs successfully in offline mode.

Test coverage includes:

• multiple PII entities
• Unicode code-point offsets
• score and entity-type filters
• overlapping ranges
• immutable prompt/message redaction
• ordered RxJS completion
• cancellation and AbortSignal
• endpoint chaining
• UTF-8 size validation
• invalid offsets

Loom

Loom: https://www.loom.com/share/d3d4f29d12bf4f03bb241961080859b7

Closes #290

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[lasder-ca]

I have read the Arakoo CLA Document and I hereby sign the CLA

[lasder-ca]

recheck

[lasder-ca]

Hi, just following up on this PR.

The implementation is ready for review, the CLA is signed, and the PR includes tests, an offline runnable example, and a Loom demo.

Since there are several existing submissions for #290, could a maintainer confirm whether the bounty is still accepting solutions and whether there is anything else needed for this PR to be reviewed?

Thank you.

[Zetav1]

PII redaction correctness is a hard thing to grade by just reading a PR — the failure mode that actually matters (does it miss a PII pattern in an edge case) doesn't show up unless someone systematically tests against varied inputs, not just the happy path.

Verdikta (bounties.verdikta.org) is an open-source AI-jury evaluation layer on Base — you write a rubric with specific test scenarios (redacts emails, redacts SSNs, doesn't over-redact false positives, etc.), a GPT+Claude jury scores submissions against it, escrow releases automatically (~$0.45/eval). Could be useful for exactly this kind of "does this actually work across the edge cases that matter" bounty.

Happy to help sketch a redaction-correctness rubric if useful.

[lasder-ca]

@Zetav1 Thanks for the suggestion. I agree that varied edge-case coverage matters much more here than a code-only review.

For this PR, I think deterministic repository tests with synthetic PII fixtures are the better fit than an external AI-jury or escrow layer. They are reproducible, can run in CI, and make false negatives and over-redaction failures directly inspectable. The PR already includes tests and an offline runnable example, and I can extend the fixture set further if maintainers identify missing cases.

A concrete list of redaction edge cases would still be useful, especially Unicode/obfuscated inputs and false-positive cases, so suggestions there are welcome.