Replace hardcoded storage adapter idempotency checks with adapter capability hooks

New Issue Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

Issue Description

For storage adapter authors, Parse Server’s request idempotency / duplicate request suppression is currently gated by concrete storage adapter classes instead of storage adapter capabilities. promiseEnsureIdempotency() currently returns early unless the adapter is an instance of MongoStorageAdapter or PostgresStorageAdapter.

That makes the storage adapter contract inconsistent: _Idempotency itself is a Parse internal class and is bootstrapped by core initialization, along with the unique reqId index, but the middleware behavior is available only to hardcoded adapter classes. A third-party or future first-party adapter cannot opt into idempotency cleanly even if it supports the needed behavior.
Currently the only workaround is to masquerade as one of the built-in adapter classes or patch Parse internals, which is brittle.

A capability check flag or function would be cleaner as an explicit storage-adapter capability instead of an instanceof MongoStorageAdapter || instanceof PostgresStorageAdapter check.

Possible ways:

adapter.capabilities?.idempotency === true
// or
typeof adapter.supportsIdempotency === 'function' && adapter.supportsIdempotency()
// or built in method calls
adapter.ensureIdempotencyIndexes?.(...)
adapter.supportsRequestDeduplication === true

Steps to reproduce

1. Implement or register a custom storage adapter that does not extend MongoStorageAdapter or PostgresStorageAdapter.
2. Make the adapter support the _Idempotency class, object creation, and uniqueness on reqId.
3. Configure Parse Server with active idempotency options
4. Send two identical write requests with same request ID; the feature does not get used.

Actual Outcome

The idempotency middleware returns early before checking the configured paths because the adapter is not an instance of MongoStorageAdapter or PostgresStorageAdapter. Duplicate request is therefore not suppressed.

Expected Outcome

A storage adapter that explicitly declares idempotency support should be able to participate in request deduplication without extending MongoDB or PostgreSQL adapter classes.

Environment

Server

• Parse Server version: alpha
• Operating system: N/A
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): N/A

Database

• System (MongoDB or Postgres): custom storage adapter
• Database version: N/A
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): N/A

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): REST
• SDK version: N/A

Logs

Relevant code paths:

src/middlewares.js
- promiseEnsureIdempotency() hardcodes MongoStorageAdapter / PostgresStorageAdapter

src/Controllers/SchemaController.js
- _Idempotency is defined as an internal/default class

src/Controllers/DatabaseController.js
- initialization enforces _Idempotency class existence
- initialization ensures uniqueness for _Idempotency.reqId
- expire/TTL idempotency index creation is also gated by Mongo/Postgres adapter checks

Start in src/middlewares.js at promiseEnsureIdempotency(), then trace _Idempotency in src/Controllers/SchemaController.js and initialization and index handling in src/Controllers/DatabaseController.js. Compare the existing MongoStorageAdapter and PostgresStorageAdapter checks with the custom-adapter flow. Done means an adapter that explicitly declares idempotency support can use request deduplication and related index handling without extending either built-in adapter.