WASB task log uploads rewrite the whole log each time instead of appending

### Description **TL;DR:** every WASB task log upload downloads the whole existing blob and re-uploads it, so one task attempt moves roughly N times its own log size across N uploads. A reschedule-mode sensor at the default 60 second poke interval moves about 2.0 GiB to store a 1.4 MiB log over 24 hours, and about 96.9 GiB to store 9.8 MiB if it runs to the default 7 day sensor timeout. The proposal is to append each new segment with an Azure AppendBlob instead of rewriting the whole object, opt-in at first. --- ## What happens today `WasbRemoteLogIO.write()` appends to a task log by rewriting the entire object. It checks whether the blob exists, downloads the complete existing log, joins it with the new content in memory, and uploads the whole result again as a block blob with `overwrite=True`. The whole retained log therefore crosses the network in both directions on every upload. One task attempt can be uploaded to many times, because the remote key comes from `try_number` and some lifecycles reuse a single attempt. A reschedule-mode sensor is the clearest case: every poke is a separate worker process, and `UP_FOR_RESCHEDULE` does not change `try_number`, so all of them write to the same `attempt=N.log`. The poke count is bounded by the sensor's timeout, but that bound is high: `[sensors] default_timeout` is 604800 seconds, so at the default `poke_interval` of 60 seconds a single attempt can reach around 10,000 uploads before it times out. What I would like is for a new segment of log to be sent as a new segment, without reading back and rewriting everything already stored. --- ## Preferred approach: Azure AppendBlob Append blobs are Azure's native answer to this. They keep one logical log object per attempt, so nothing on the read path or in the UI has to change in the normal case, and the diff is contained inside this provider. The local-segment behavior proposed in #70860 makes the flow below possible. With that change, the local log file holds exactly the cur…