`#[derive(IntoPyObject)]` error a bit unhelpful when lifetime not called `'py`

In pydantic-core some (legacy) lifetimes were 'a instead of 'py, and using the new #[derive(IntoPyObject)] led to some interesting errors:

use pyo3::{Bound, IntoPyObject, PyAny};

#[derive(IntoPyObject)]
pub struct Wrap<'a>(Bound<'a, PyAny>);

gets lots of errors like

error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'py` due to conflicting requirements
 --> src/lib.rs:3:10
  |
3 | #[derive(IntoPyObject)]
  |          ^^^^^^^^^^^^
  |
note: first, the lifetime cannot outlive the lifetime `'a` as defined here...
 --> src/lib.rs:4:17
  |
4 | pub struct Wrap<'a>(Bound<'a, PyAny>);
  |                 ^^
note: ...but the lifetime must also be valid for the lifetime `'py` as defined here...
 --> src/lib.rs:3:10
  |
3 | #[derive(IntoPyObject)]
  |          ^^^^^^^^^^^^
note: ...so that the types are compatible
 --> src/lib.rs:3:10
  |
3 | #[derive(IntoPyObject)]
  |          ^^^^^^^^^^^^
  = note: expected `pyo3::IntoPyObject<'py>`
             found `pyo3::IntoPyObject<'_>`
  = note: this error originates in the derive macro `IntoPyObject` (in Nightly builds, run with -Z macro-backtrace for more info)

changing the struct lifetime from 'a to 'py trivially resolves, though I wonder if there's any tricks we can do to improve the UX 🤔

Start by reproducing the provided #[derive(IntoPyObject)] example with the lifetime named 'a rather than 'py. Inspect the IntoPyObject derive macro's diagnostic path and determine how its lifetime error is presented. Done means the reported error gives more useful guidance for this case without breaking the existing derive behavior.