HIP-1215 scheduleCall dispatch returns INVALID_CONTRACT_ID on testnet despite being listed as enabled

On current **testnet**, calling `scheduleCall` on the Schedule Service system contract (`0x16b`) from a contract fails with network-level `INVALID_CONTRACT_ID` (mirror-node record, consensus ts `1787648020.092466376`), while the view `hasScheduleCapacity` on the same address answers correctly via staticcall.

Reproduced with expiries ~15 minutes AND ~24 days out, with value attached, from a Sourcify-verified contract ([0.0.10205676](https://hashscan.io/testnet/contract/0.0.10205676), `scheduleSettlement` — it wraps `scheduleCall(address(this), gasLimit, 0, expiry, calldata)` per HIP-1215).

Release notes indicate HIP-1215 generalized scheduled contract calls enabled since v0.68 (with a facade fix in 0.69.1). Is the state-changing dispatch currently feature-flagged off on testnet? If so, it would help if the docs/release notes said so — `hasScheduleCapacity` answering `true` while `scheduleCall` rejects makes integrators suspect their own code first (we spent a debugging session on exactly that before mirror-node forensics pointed at the network response).

Happy to provide additional transaction ids or run further probes on request.

Start with HIP-1215 and the v0.68 and v0.69.1 release notes, then compare the scheduleCall dispatch path with the hasScheduleCapacity view on testnet. Use the supplied contract and mirror-node evidence to determine whether dispatch is feature-flagged; done means the behavior is corrected or the testnet limitation is clearly documented.

Written by the indexing model from the issue text.