Crash when tilemap is created without a tileset image

## Bevy version and features
0.17.2, default features

## What you did

Code is a minimized version of the Tilemap example (https://bevy.org/examples/2d-rendering/tilemap-chunk/). The error occurs when a tilemap is spawned, but not given an image handle for its tileset, so the default image handle is used.

```rs
use bevy::{
prelude::*,
sprite_render::{TileData, TilemapChunk, TilemapChunkTileData},
};

fn main() {
App::new()
.add_plugins(DefaultPlugins)
.add_systems(Startup, setup)
.run();
}

fn setup(mut commands: Commands, assets: Res) {
let chunk_size = UVec2::splat(64);
let tile_data: Vec> =
vec![Some(TileData::from_tileset_index(0)); chunk_size.element_product() as usize];

commands.spawn((
TilemapChunk {
chunk_size,
tile_display_size: UVec2::splat(8),
// Omiting this line causes the error
tileset: assets.load("textures/array_texture.png"),
..default()
},
TilemapChunkTileData(tile_data),
));

commands.spawn(Camera2d);
}
```

## Observed behavior

```
thread 'Compute Task Pool (1)' panicked at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\backend\wgpu_core.rs:1195:26:
wgpu error: Validation Error

Caused by:
In Device::create_bind_group, label = 'TilemapChunkMaterial'
Texture binding 0 expects dimension = D2Array, but given a view with dimension = D2

stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library\std\src\panicking.rs:697
1: core::panicking::panic_fmt
at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library\core\src\panicking.rs:75
2: wgpu::backend::wgpu_core::default_error_handler
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\backend\wgpu_core.rs:659
3: wgpu::backend::wgpu_core::ErrorSinkRaw::handle_error
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\backend\wgpu_core.rs:643
4: wgpu::backend::wgpu_core::ContextWgpuCore::handle_error_inner
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\backend\wgpu_core.rs:298
5: wgpu::backend::wgpu_core::ContextWgpuCore::handle_error >
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\backend\wgpu_core.rs:311
6: wgpu::backend::wgpu_core::impl$12::create_bind_group
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\backend\wgpu_core.rs:1195
7: wgpu::api::device::Device::create_bind_group
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-26.0.1\src\api\device.rs:220
8: bevy_render::renderer::render_device::RenderDevice::create_bind_group > > >
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\bevy_render-0.17.2\src\renderer\render_device.rs:154
9: bevy_render::render_resource::bind_group::AsBindGroup::as_bind_group
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\bevy_render-0.17.2\src\render_resource\bind_group.rs:548
10: bevy_sprite_render::mesh2d::material::impl$21::prepare_asset
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\bevy_sprite_render-0.17.2\src\mesh2d\material.rs:986
11: bevy_render::render_asset::prepare_assets >
at C:\Users\~\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\bevy_render-0.17.2\src\render_asset.rs:398
12: core::ops::function::FnMut::call_mut,bevy_ecs::change_detection::ResMut,void (*)(bevy_ecs::change_detection::ResMut>`!
```

## Expected behavior

I believe an error like this should not crash the app, but should simply not render anything. Specifically, if an image handle is provided, the app does not crash, even if the image file does not actually exist.

## Additional information

It seems the default image has a dimension that is incompatible with a tileset image, which the bind group violently rejects. On the other hand, when the asset fails to load because the file does not exist, the app does not crash because `prepare_assets` does not run at all.

Reproduce the crash with the minimized TilemapChunk example, then start at TilemapChunkMaterial and the prepare_assets path named in the backtrace. Check the default tileset image and bind-group preparation; done means omitting the image handle no longer panics and the tilemap simply does not render.

Written by the indexing model from the issue text.