Do not treat expirations as engine-level thing for regular objects

Is your feature request related to a problem? Please describe.

I'm always frustrated when I realize that we're doing things we can avoid.

Describe the solution you'd like

Simple object expiration can be final at the shard level. Split objects do require some passing to engine level since we need to release all associated children, but simple objects are simple. The only thing that can prevent their expiration is lock. Locks should always be put into shards that have respective objects (they're associated). What can prevent this from happening is shard being RO in which case lock should be put into some available shard, but marked for subsequent move (RO shard doesn't delete objects anyway). Local state can then be leveraged to mark previously degraded shards and deal with moves before starting the GC (but after a shard becoming RW).

Describe alternatives you've considered

Some things can be discussed here.

The issue names no files, tests, or entry points. Start by locating the expiration, shard, lock, and GC flows, then determine how simple and split objects are distinguished. Done means simple-object expiration is finalized at the shard level while split objects retain the required engine-level coordination and deferred moves from read-only shards.