Infer reverse table relationship for ad-hoc queries (when not declared in schema)

**Investigative — needs design.** A relationship declared in only one direction (e.g. `Challenge.questions: [Question] @relationship(to: "challengeId")` without an inverse `Question.challenge`) is invisible from the other side. Enable ad-hoc queries to traverse the inverse direction without requiring the user to declare it explicitly.

## Example schema

```graphql
type Challenge @table @export {
id: Int @primaryKey
questions: [Question] @relationship(to: "challengeId")
}

type Question @table {
id: Int @primaryKey
challengeId: Int @indexed
}
```

A user wanting to query "for this Question, what Challenge does it belong to?" today must explicitly declare the inverse.

## Why this isn't a slam-dunk

From the Jira discussion (Kris): _"It seems like this requires a lot of assumptions about how the inverse relationship should work, what the name is, and if the user even wants it to be exposed."_

Open design questions:
- **Naming:** what name should the inferred inverse field take? `challenge` (singular of source type)? `Challenge`? Customizable?
- **Cardinality:** the original `[Question]` declares many-from-one. The inverse is always one-from-one (by primary key) — but does the user want it exposed at all?
- **Privacy/exposure:** declared relationships are explicit user intent. Auto-exposing them changes the API surface without user opt-in. Could break schemas with sensitive cross-table data.
- **Ad-hoc only?** Devin suggested ("Maybe if you're explicitly asking for it somehow in the search?") an opt-in path: only resolve the inverse when the query explicitly asks for it (e.g. a flag in `search_by_conditions`), so the schema's exported surface is unchanged.

## To investigate

- Sketch the explicit-opt-in version (Devin's suggestion). What does the search syntax look like?
- For SQL (where joins are inherently ad-hoc), does the AlaSQL path already handle this if the foreign key is `@indexed`? If so, the gap is specifically the operations-API / GraphQL exposure.
- Decide whether this is even worth the design churn given the workaround is "declare the inverse in your schema" (a single-line GraphQL change).

## Not Ready

Until a concrete syntax + semantics proposal exists. Low priority per Jira.

---

Tracked in Jira: [CORE-3032](https://harperdb.atlassian.net/browse/CORE-3032)

🤖 Filed by Claude on behalf of Kris.