[Bug]: GetResourceOperationStatus creates a StatusMonitor endpoint that is a child of the resource, causing a problem for lro deletes

### Describe the bug

When deleting a resource in an asynchronous way, the `LongRunningResourceDelete` operation emits an endpoint that is a children of the resource being deleted.

``` typescript
interface Widgets {
/** Get status of a Widget operation. This operation return status in status code. No response body is returned. */
getWidgetOperationStatus is Operations.GetResourceOperationStatus;

/** Delete a Widget asynchronously. */
@pollingOperation(Widgets.getWidgetOperationStatus)
deleteWidget is Operations.LongRunningResourceDelete;
}
```

The endpoints created are:

```
DELETE /widgets/{widgetId}
GET /widgets/{widgetId}/operations/{operationId}
```

The problem is when the widget resource is deleted, the endpoint `/widgets/{widgetId}/operations/{operationId}` should not be accessible anymore. And, if the operation status endpoint should still be accessible even if the resource isn't, what is the expected behavior if a new resource with the same ID is created? The [documentation](https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#delete-lro-pattern) and [examples](https://azure.github.io/typespec-azure/docs/getstarted/azure-core/step06/) provided are confusing regarding this topic.

### Reproduction

See this [playground](https://azure.github.io/typespec-azure/playground/?c=aW1wb3J0ICJAdHlwZXNwZWMvcmVzdCI7DQrSGnZlcnNpb25pbmfNIGF6dXJlLXRvb2xzL8gsLWF1dG%2FRStYqxRVjb3JlxCwNCnVzaW5nIEh0dHA7yA1SZXN0yQ1W6QCGyRNBxEMuQ29yZdMTLlRyYWl0c8VcQHNlcnZpY2UoI3t0aXRsZTogIkRlbW8gxxcifSkNCkB1c2VEZXBlbmRlbmN5KMtJx3pzLnYxXzBfUHJldmlld18yKQ0KbmFtZXNwYWNlIEFzeW5jRGVsZXRlxFrFdmFsaWFzIFPGZOYAjiA9IFN1cOQBF3NSZXBlYXRhYmxlUmVxdWVzdHMgJg0KIMkgQ29uZGl0aW9uYWzXIWxpZW50xxxJZMtzT3BlcmHEO8Rw6wDJUmVzb3VyY2XKIDztAJ4%2BxUQvKiogQSB3aWRnZXQuICovDQpAcsc5KCLGF3MiKQ0KbW9kZWwgV8URIHvkAJpAa2V5yCNJZMQkICBAdmlzaWJpbGl0eShMaWZlY3ljbOQAimFkxR%2FEbVRoZcdvIElExnIgIGlkOiBzdHLmAe995ACYaW50ZXJm5AFtxnRzxnXEQkdldCBzdGF0dXMgb2YgYcchIG%2FoAOguIFRoaXPKECByZXR1cm7INGnJCmNvZGUuIE5vIHJlc3BvbnNlIGJvZHkgaXPHMmVk6ACgZ2V0xmbpAU1Tx03sAYAuR2V08QF2xik8xj8sIG5ldmVy5gF75gDO5gJH6gDHYeQCXGhyb25vdXNseegAgUBwb2xsaW5nyVcoxi9zLvgAm%2BUBcWTFXcda7gCsTG9uZ1J1buQDY%2BgAtOYAi%2BcAq%2BQApH0%3D&e=%40azure-tools%2Ftypespec-autorest&options=%7B%7D).

### Checklist

- [x] Follow our [Code of Conduct](https://github.com/azure/typespec-azure/blob/main/CODE_OF_CONDUCT.md)
- [x] Check that this issue is about the Azure libraries for typespec. For bug in the typespec language or core libraries file it in the [TypeSpec repo](https://github.com/Microsoft/TypeSpec/issues/new/choose)
- [x] Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
- [x] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

Start with the linked playground reproduction, then compare the delete LRO pattern in the linked API guidelines and Azure examples. Clarify whether the status endpoint must remain reachable after deletion and how reused resource IDs behave; done means the project's behavior and documentation/examples agree.

Written by the indexing model from the issue text.