Contradiction on Placement page: RPC methods statement vs. "Multiple Workers" example

### Existing documentation URL(s)

**Page:** https://developers.cloudflare.com/workers/configuration/placement/

The page contains two statements that appear to contradict the example in the "Multiple Workers" section.

## The statements

Under both the Smart Placement and Placement sections, the page says (twice, verbatim):

> Placement only affects the execution of fetch event handlers. It does not affect RPC methods or named entrypoints.
>
> Workers without a fetch event handler are ignored by placement.

## The example that contradicts them

The "Multiple Workers" section recommends splitting an app into an `auth-worker` (no placement) and an `app-worker` (placed near the database, communicating via Service Binding RPC). The `app-worker` is a `WorkerEntrypoint` whose only `fetch()` handler is a stub returning 404:

```ts
export default class AppWorker extends WorkerEntrypoint {
async fetch() {
return new Response(null, { status: 404 });
}

// Each method runs near your database - multiple queries stay fast
async getUser(userId: string) { /* ... */ }
async getUserListings(userId: string) { /* ... */ }
}
```

The comment in the code asserts `// Each method runs near your database`, and the paragraph below the example states:

> Authenticated requests are forwarded via RPC to `app-worker`, which runs near your database for fast queries.

This directly contradicts "Placement … does not affect RPC methods or named entrypoints."

## What's unclear

It's not possible from the page alone to tell which is true:

1. **Does placement affect where RPC methods execute** when the entrypoint is invoked via Service Binding? The example implies yes; the disclaimer says no.
2. **What is the role of the stub `fetch()`** in the example? Is it required only so the Smart Placement engine doesn't ignore the Worker (per "Workers without a fetch event handler are ignored by placement"), while explicit `region` placement applies regardless? Or does the stub do nothing and the example is misleading?
3. Does the "does not affect RPC methods" sentence perhaps refer only to **Smart Placement's decision input** (i.e., the algorithm observes fetch traffic, not RPC traffic, when deciding where to place), and not to where RPC methods actually execute once a placement is set?

### What changes are you suggesting?

Either:

- **If RPC methods do run at the placed location**: remove or rewrite the "does not affect RPC methods or named entrypoints" sentence, and explain that a (possibly stub) `fetch()` handler is required for the Worker to be considered by placement.
- **If RPC methods do not run at the placed location**: rewrite the "Multiple Workers" example, because as written it teaches a pattern that doesn't deliver the latency benefit it claims.

Either way, please clarify the role of the stub `fetch()` handler in the recommended pattern.

### Additional information

_No response_