Therefore, I believe an argument can be made, that the beep and green light are confirmation that the OP had a 'valid ticket' at the time of boarding the train. I wouldn't necessarily expect such an argument to succeed.
I would be inclined to favour this argument, albeit with some hesitation.
The technical architecture of the Oyster system, as with almost all MIFARE-style contactless automatic fare collection systems, is such that the data on the actual card is treated as the authoritative record. It has to be, since there wasn't (and really still isn't) a means by which validators could 100% reliably query from and write to a central database in the tiny span of time allowed. This design introduces the weakness seen with card-not-present actions, like top-ups and cancellations - the update has to propagate through the system, and then wait on the system until the card is presented and updated.
Now, given what MikeWh put it in
post 38 regarding the six months a record sits on the FUL list, we know that the OP wouldn't have had this problem had they attempted to use the card within six months of requesting cancellation: the card would have been cancelled and rejected by the first validator to which the OP touched it. However, since the card had dropped off the FUL list and thus wasn't cancelled at either of the OP's touch-ins, I do see grounds that favour the argument that the card was validly accepted for travel based on Condition 3.4.
I do, nonetheless, see an open question regarding the
appearance of intent on behalf of the OP. It would be easy for TfL to argue that their call handler explained that they would be cancelling the card, in which case it could perhaps be read that the OP was negligent in keeping the card - because, after all, if they had destroyed it then and there they wouldn't have been able to get themselves into this situation.