cli: Add RESOURCE_BUCKET_INFO to fossilize-list tag_names

[louzt]

cli: Add RESOURCE_BUCKET_INFO to fossilize-list tag_names

Problem

PR #308 (bucket-json-system, merged via 0ae323c) introduced
RESOURCE_BUCKET_INFO = 10 to the ResourceTag enum in
fossilize_types.hpp so the bucket manifest can be stored as a
separate DB entry alongside the RESOURCE_* pipeline tags.

cli/fossilize_list.cpp was not updated to match. The
tag_names[] array still enumerates indices 0..9 only, leaving
three concrete failures:

1. fossilize-list --help lists tags 0..9, silently hiding tag 10.
   Users with .foz files that contain RESOURCE_BUCKET_INFO
   entries (any application that ran with the bucket layer
   enabled, e.g. Steam on Palworld) cannot discover the tag from
   the help output.
2. fossilize-list --tag 10 is accepted by the guard
   tag_uint >= RESOURCE_COUNT (since RESOURCE_COUNT = 11),
   but then fails with a generic "Failed to get hashes." log line
   that doesn't help the user understand the tag is real but
   unlisted.
3. fossilize-list --connectivity against a .foz that contains
   RESOURCE_BUCKET_INFO entries performs an out-of-bounds array
   read at tag_names[par.first] when par.first == 10. The
   behavior is undefined; in practice it has caused garbage pointer
   dereferences during palworld/Vulkan cache inspection.

Solution

Two surgical changes in cli/fossilize_list.cpp:

1. Append "bucketInfo" to tag_names[] so the array has
   exactly RESOURCE_COUNT entries.
2. Add a static_assert that
   sizeof(tag_names) / sizeof(tag_names[0]) == RESOURCE_COUNT
   with a message pointing future contributors to the source of
   truth (fossilize_types.hpp).

Both print_help() (which iterates i < num_tags) and the
runtime tag_names[par.first] lookup now resolve tag 10
correctly. The static_assert closes the same class of drift that
e4ec0c1 ("Fix broken tag names lut in fossilize-list.",
2025-11-10) fixed for computePipeline, so this regression
cannot recur silently.

Scope Boundary

This PR does not modify:

• Database storage (fossilize_db.{hpp,cpp}) — the 39004ff
  bucket-info entry is read as-is.
• The replayer (cli/fossilize_replay.cpp) — f0270fe already
  logs Replaying for bucket: ... upstream.
• The Vulkan layer (layer/instance.cpp) — bucket info is set
  by libVkLayer_steam_fossilize.so at recording time.
• #310 (roundtrip-checker, Draft) — orthogonal concern
  focused on Mesa CI driver invariance; this fix is a
  pre-requisite for inspecting any .foz produced by the
  bucket layer.

Validation

# Build
cmake --build build --target fossilize-list

# Help now lists tag 10:
$ ./build/cli/fossilize-list --help
  ...
  10: bucketInfo

# Tag 10 is now accepted:
$ ./build/cli/fossilize-list --tag 10 /path/to/.foz
# prints hashes for any RESOURCE_BUCKET_INFO entries

# Tag 11 (out of range) still fails cleanly:
$ ./build/cli/fossilize-list --tag 11 /path/to/.foz
  Fossilize ERROR: --tag (11) is out of range.

# Connectivity no longer OOBs:
$ ./build/cli/fossilize-list --connectivity /path/to/.foz
  # prints entries with "bucketInfo(...)" labels

# Static_assert trips the build if tag_names/RESOURCE_COUNT
# drift apart again — drop a new ResourceTag enum and the
# compiler will tell you to extend tag_names[].

References

• Add a system to determine what a Fossilize bucket corresponds to #308 — bucket-json-system (Plagman): introduced
  RESOURCE_BUCKET_INFO = 10 and RESOURCE_COUNT = 11.
• e4ec0c1 — "Fix broken tag names lut in fossilize-list."
  (Hans-Kristian Arntzen, 2025-11-10): same pattern of fix for
  computePipeline; this PR extends the same safeguard.
• e2169ee — "fossilize-list: List all tags in --help."
  (Hans-Kristian Arntzen): made the help iteration
  num_tags-driven, so adding one entry to the array
  automatically exposes the new tag in --help.
• bdaff23 — "Add log connectivity parameter to fossilize-list."
  (Add log connectivity parameter to fossilize-list #284): introduced the tag_names[par.first] lookup that
  this PR now makes safe for tag 10.

[HansKristian-Work]

tl;dr. This really should have been a two-line PR description.