Add `BadgerDBFindOne` method for `DriverMessageModel`

[jim-junior]

Description

Extend the DriverMessageModel struct by implementing a new standalone query method called BadgerDBFindOne. To ensure backward compatibility and prevent downstream integration issues, do not refactor, rename, or drop the current etcd-based FindOne implementation. This method introduces native support to fetch and deserialize a specific driver message entry directly from BadgerDB.

Requirements

• File Location: internal/models/messages.go
• Method Signature Strategy: Introduce a new method named BadgerDBFindOne(id string) (*craneTypes.DriverMessage, error) on the DriverMessageModel struct.
• Transactionality: Execute the key search completely inside a BadgerDB View (read-only) transaction.
• Key Generation: Compute the precise lookup key using the struct's prefix and the requested ID parameter: m.Prefix + id (yielding driver-messages/{id}).
• Data Retrieval & Deserialization:
  • Fetch the matched record inside the transaction context.
  • Safely extract the byte array payload following BadgerDB's item lifecycle guidelines (e.g., calling item.ValueCopy()).
  • Unmarshal the raw JSON bytes back into a reference of craneTypes.DriverMessage via the standard json.Unmarshal package.
• Error Handling: If the calculated key is missing from the database structure (errors.Is(err, badger.ErrKeyNotFound)), return a descriptive custom error matching the context of the etcd legacy counterpart: fmt.Errorf("message not found: %v", err).
• Testing: Author a standalone unit test variant inside internal/models/messages_test.go to validate successful data parsing, property integrity, and error routing scenarios against an in-memory BadgerDB engine instance.

Success Criteria

• The BadgerDBFindOne method is cleanly exposed on the target model alongside older data paths without modifying existing public API signatures.
• Stored record verification wraps lookup queries safely inside a read-only View routine block.
• Querying an unknown message ID string reliably surfaces the expected custom message not found text formatting.
• Test Case implementation: A comprehensive unit test is provided that:
  • Seeds an isolated, in-memory BadgerDB instance with a temporary pre-marshaled driver message payload.
  • Successfully calls BadgerDBFindOne with the matching tracking ID.
  • Asserts that the decoded properties are equivalent to the originally injected values.
  • Asserts that trying to read a random, nonexistent key drops out with the required custom error context.