Capability metadata + compatibility mode

[REASY]

Goal

Let clients detect what the GraphQLite engine supports and avoid brittle fallbacks.

Problems Observed

• Clients must guess whether bracket access, list literals, or nested maps are supported.
• No programmatic way to inspect features or dialect version.

Proposed Changes (graphqlite)

• Expose a capabilities() API that returns:
  • Cypher dialect version.
  • Supported syntax flags (bracket access, list literals, map/list properties, backticks, JSON path).
  • JSON1 availability.
• Optional compatibility mode toggles (e.g., enable_neo4j_compat).

Acceptance Criteria

• Client can query capabilities at runtime and adjust behavior.
• Capability info is versioned and documented.

Implementation Notes

• Add a lightweight metadata struct to Rust API.
• Keep backward compatibility by defaulting to current behavior.

[dylanbstorey]

If understand this request correctly, I don’t think it supports the goal of the project is to be compatible with open cypher spec; not to be a compatible (or provide guaranteed compatibility) with dialects. I’m not going to prioritize this over some other issues you’ve opened.

If you feel strongly about this i’m happy to take pull requests still.