Clarify transaction behavior w.r.t. archived entries

[dmkozh]

It's important to document the expectations around the behavior of transactions with regards to the archived entries, specifically, we should state that:

• Any Soroban transaction that has a key of an archived Persistent entry in the footprint will fail immediately during apply stage
• An important security implication is that archived persistent entries can never be re-created. They only can be restored and then updated/removed
• The failed transaction can never reach the smart contract logic, i.e. smart contracts can always assume that they never access archived entries and thus there is no need to write any special logic for handling the archival
• The statement above is also relevant for the contract unit tests - it makes sense to cover the TTL extension logic, but there isn't much value in trying to cover the archival behavior (it will be possible to do to some degree, but it doesn't need to be promoted as a default testing practice)

This may be added as a part of revisiting state archival documentation in general (#327), but I think some of the key points could be reiterated in a more discoverable page (specifically the point about contracts never accessing the archived entries)