[core] Move Fallible into Arc<Texture>

[sagudev]

Connections
Link to the issues addressed by this PR, or dependent PRs in other repositories

When one pull request builds on another, please put "Depends on
#NNNN" towards the top of its description. This helps maintainers
notice that they shouldn't merge it until its ancestor has been
approved. Don't use draft PR status to indicate this.

Description
We move Fallible into Arc<Texture>. More specifically we now have:

pub enum DestructibleResourceState<T> {
    Valid(T),
    Invalid,
    Destroyed,
}

in somekind of snatchable. We now have create_texture_inner( self: &Arc<Device>, desc: &resource::TextureDescriptor, ) -> Result<Arc<Texture>, resource::CreateTextureError>
which is called by
pub fn create_texture( self: &Arc<Device>, desc: &resource::TextureDescriptor, ) -> (Arc<Texture>, Option<resource::CreateTextureError>)
this will also make sense when we do #8911.

There are some things to note here:

• we should probably trace invalid objects
• we sometimes report object as destroy instead of invalid
• the only way object can become invalid is when create_* so we do not need to have snatchable on nondestructable resources

Testing
Explain how this change is tested.

Squash or Rebase?

If your pull request contains multiple commits, please indicate whether
they need to be squashed into a single commit before they're merged,
or if they're ready to rebase onto trunk as they stand. In the
latter case, please ensure that each commit passes all CI tests, so
that we can continue to bisect along trunk to isolate bugs.

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Validation and feature gates are in place to confine behavioral changes.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.