Security bug: Oracle attack surface in sample webhook app

The sample Typescript app to implement Esri Online webhooks exposes the server to a classic [oracle attack](https://en.wikipedia.org/wiki/Oracle_attack):

https://github.com/Esri/webhooks-samples/blob/cae894a4dfe8fe7b48ed8fa541fe812a8ff12407/Developer/typescript/node.js/src/app.ts#L77-L79

In specific, this sample code allows arbitrary `crc_token` values, including those for valid webhook payloads (JSON, URL-encoded, etc.).

That means an attacker can fashion a `crc_token` value with an arbitrary attacker-controlled webhook payload. The server will happily generate and return to the attacker a valid HMAC of that malicious payload on its behalf.

Because the `crc_token` `GET` path and the webhook payload `POST` path use the same signing key, the attacker can then send another request with its malicious payload and the HMAC returned by the server to bypass signing key verification (without knowing the signing key itself).

The simplest fix is twofold:

1. Update the docs to clarify that `crc_token` is always alphanumeric (`^[a-zA-Z0-9]+$`). This is already the case today, it's just not documented at https://developers.arcgis.com/rest/services-reference/online/web-hooks-security-feature-service/#example-usage-immediate-webhook-confirmation .
2. Update the example app to enforce that `crc_token` is always alphanumeric and reject any token values which do not match `/^[a-zA-Z0-9]+$/`.

Alternatively, Esri can require separate signing keys for CRC token validation and webhook payload signing, but that is a much larger change.

Start with Developer/typescript/node.js/src/app.ts at lines 77-79 and review the immediate webhook confirmation path alongside the POST signing path. Check the linked ArcGIS webhook security documentation for the crc_token format. Done means the example rejects tokens that do not match the specified alphanumeric format and the documentation states that requirement.

Written by the indexing model from the issue text.