Honor CREATE REL TABLE storage_direction in edge CSR layout

[liulx20]

Summary

CREATE REL TABLE ... WITH (storage_direction = 'fwd'|'bwd'|'both') was parsed and kept in binder / catalog options, but execution ignored it when building OE/IE strategies. Multiplicity alone always created both CSR sides, so one-sided storage never took effect and binder checks against EdgeSchema.oe/ie_strategy were effectively no-ops for Cypher-created tables.

Expected behavior

storage_direction	Storage
fwd	OE only (ie = kNone / EmptyCsr)
bwd	IE only (oe = kNone / EmptyCsr)
both (default)	both sides

Schema dump / checkpoint should persist x_csr_params.edge_storage_strategy as ONLY_OUT / ONLY_IN so reopen round-trips.

Binder should reject patterns that would scan the missing side (e.g. undirected on fwd, directed on bwd-only).

Remaining follow-ups

• Default DP planner respects getExtendDirections(), but the join-hint path (JoinPlanSolver) does not check available storage directions before appendExtend, so a hint-driven plan could still try to expand on an EmptyCsr side.
• Execution has no secondary guard; EmptyCsr::get_generic_view is FATAL if misused.

Related

Local commit: 803af0d — wires option through DDL converter / CreateEdgeTypeOpr, schema dump, and unit/e2e/python tests.

[github-actions]

🤖 Auto-triage: could not confidently classify this issue under any current v0.2 umbrella.

Reason: The issue is about honoring the storage_direction option in CREATE REL TABLE for edge CSR layout, which is a core storage/schema feature that does not fit any specific umbrella's scope_in.

Auto-applied: type → Feature

Maintainers: please pick a parent manually, or close if out of scope.