ecosystem/graphql builds against remote master rather than the checkout it lives in

## Summary

`ecosystem/graphql/WORKSPACE:224` pulls this project in over the network:

```python
git_repository(
name = "com_resdb_nexres",
branch = "master",
remote = "https://github.com/apache/incubator-resilientdb.git",
)
```

The subproject is vendored in the same repository, but depends on its parent as
if it were a separate one. With this default wiring, an ordinary GraphQL build
does not see parent changes until they are merged to master; testing them
earlier requires an explicit `local_repository` or `--override_repository`,
which nothing in the tree sets up.

## Demonstration

With local modifications present in the checkout, `@com_resdb_nexres` resolves
to different content than the working tree it sits in:

```
working tree:
service/tools/kv/api_tools/kv_service_tools.cpp:129 int c;
repositories.bzl:75 strip_prefix = "abseil-cpp-20240722.2"

what ecosystem/graphql resolves @com_resdb_nexres to:
service/tools/kv/api_tools/kv_service_tools.cpp:127 char c;
repositories.bzl:59 strip_prefix = "abseil-cpp-20211102.0"
```

Both listings are from the same container in the same run. The second is
whatever master happens to be at fetch time.

## Why it matters

With the default wiring, an ordinary GraphQL build does not exercise parent
changes before they are merged. A change that builds and passes everywhere in
this repository can still break GraphQL, and seeing that beforehand requires an
explicit `local_repository` or `--override_repository`, which nothing in the
tree sets up.

Note that this does not by itself hold GraphQL on the old Abseil: that
workspace declares `com_google_absl` 20211102.0 itself at
`ecosystem/graphql/WORKSPACE:135` (line numbers as of master at the time of
writing), and because the parent registers Abseil through `maybe(...)` an
already-declared repository is not replaced. Re-fetching remote master updates
the parent's own sources and BUILD files, not GraphQL's dependency pins.

The effect is that the subproject lives in this tree but integrates like an
external one: changes here and changes there only meet after a merge and a
re-fetch.

## Two related observations in the same file

**No `.bazelversion` or `MODULE.bazel`.** Since `ecosystem/graphql` has its own
`WORKSPACE`, Bazelisk treats it as the workspace root and finds no version
file, so it falls back to the latest Bazel:

```
bazelisk in the project root: bazel 6.0.0
bazelisk in ecosystem/graphql: bazel 9.2.0
```

Bazel 9 no longer reads `WORKSPACE`, so under it nothing in that file is
visible at all:

```
ERROR: No repository visible as '@com_resdb_nexres' from main repository
```

Forcing `USE_BAZEL_VERSION=6.0.0` is what made the demonstration above
possible. The root `.bazelversion` is not inherited because Bazelisk stops at
the nearest workspace root.

**Dependencies without integrity checks.** `hedron_compile_commands`,
`com_google_protobuf` (a `git_repository` on a mutable tag), `com_google_absl`,
`com_github_nelhage_rules_boost`, `pybind11_bazel` and `com_resdb_nexres`
itself all lack a `sha256`, and the Abseil pin is the 20211102.0 that does not
compile with GCC 13+.

## Not claimed here

I did not establish whether `ecosystem/graphql` builds successfully today. The
fetch I used to produce the listing above also reported
`@com_google_leveldb ... is not defined`, but I asked for
`@com_resdb_nexres//service/kv:kv_service`, which may simply not be a target
this subproject builds. That part needs someone who knows the intended entry
points.

## Possible direction

`local_repository(name = "com_resdb_nexres", path = "../..")` would make the
dependency point at the checkout, so changes are testable before merge. Whether
that is right depends on how the subproject is meant to be released and
consumed, which is a decision for the maintainers rather than something to
change from outside.

Found while working on #245.