fix: explain the hostname requirement when the executor cannot find its own container

[HarshMN2345]

On startup the executor finds its own container by filtering container names with its hostname, and Docker's name filter matches any name that contains it. When the hostname is not part of the container name (Appwrite up to 1.9.0 used hostname exc1 with container_name openruntimes-executor), startup failed with a bare "Own container not found". The error now names the hostname it looked up and says how to fix it, and the README explains the lookup and suggests using the container name as the hostname. The logging part of the issue is already handled upstream, since the executor ships utopia-php/http rc23 or later, which keeps this exception as the previous one when the error hook fails.

Fixes appwrite/appwrite#13016

[greptile-apps]

Confidence Score: 4/5

[Low risk] Improves error message and documentation for container startup.

The PR appears safe to merge, though the README guidance should be made consistent with its example.

Findings

1.  Conflicting hostname guidance ▶

Fix with agent prompt

### Issue 1
README.md:77
The example directly above sets `hostname: executor` and `container_name: openruntimes-executor`. It works because the hostname is part of the container name, but the new note recommends using the entire container name as the hostname. Clarifying why the example works would keep readers troubleshooting startup from receiving conflicting guidance.

```suggestion
> On startup, executor looks up its own container by hostname to connect it to the runtime networks, and exits if the hostname is not part of any container name. In the example above, `executor` is part of `openruntimes-executor`, so the lookup succeeds; using the full container name as the hostname avoids relying on a partial match.
```

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds the hostname and a suggested remedy to the own-container startup error, and documents the hostname-based lookup in the README.

• The new README guidance conflicts with the values in its getting-started example.

_{Reviews (1) · Last reviewed commit: "fix: describe the own container lookup a..."}

[greptile-apps]

Conflicting hostname guidance The example directly above sets hostname: executor and container_name: openruntimes-executor. It works because the hostname is part of the container name, but the new note recommends using the entire container name as the hostname. Clarifying why the example works would keep readers troubleshooting startup from receiving conflicting guidance.

Suggested change

	> On startup, executor looks up its own container by hostname to connect it to the runtime networks, and exits if the hostname is not part of any container name. Using the container name as the hostname is the safest setup.
	> On startup, executor looks up its own container by hostname to connect it to the runtime networks, and exits if the hostname is not part of any container name. In the example above, `executor` is part of `openruntimes-executor`, so the lookup succeeds; using the full container name as the hostname avoids relying on a partial match.

Prompt To Fix With AI

This is a comment left during a code review.
Path: README.md
Line: 77

Comment:
**Conflicting hostname guidance** The example directly above sets `hostname: executor` and `container_name: openruntimes-executor`. It works because the hostname is part of the container name, but the new note recommends using the entire container name as the hostname. Clarifying why the example works would keep readers troubleshooting startup from receiving conflicting guidance.

```suggestion
> On startup, executor looks up its own container by hostname to connect it to the runtime networks, and exits if the hostname is not part of any container name. In the example above, `executor` is part of `openruntimes-executor`, so the lookup succeeds; using the full container name as the hostname avoids relying on a partial match.
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!