Locating the original query once it's been transpiled to sql syntax from sqlair is non-obvious

~~I'm not expecting this to be solved now (or ever), but just an observation.~~ Once queries have been transpiled from sqliar to SQL, locating the original query is no longer just a grep.

Consider the following output in the logs:

```sql
SELECT u.external AS _sqlair_0,
p.access_type AS _sqlair_1, p.uuid AS _sqlair_2
FROM v_user_auth u
LEFT JOIN v_permission p ON u.uuid = p.grant_to AND p.grant_on = @sqlair_0
WHERE u.name = @sqlair_1
AND u.disabled = false
AND u.removed = false
```

This was the original output:

```sql
SELECT (u.external) AS (&dbPermissionUser.*),
(p.access_type, p.uuid) AS (&dbPermission.*)
FROM v_user_auth u
LEFT JOIN v_permission p ON u.uuid = p.grant_to AND p.grant_on = $dbPermission.grant_on
WHERE u.name = $dbPermissionUser.name
AND u.disabled = false
AND u.removed = false
```

The issue names no files, tests, or entry points. Start by tracing where sqlair queries are transpiled to SQL and where the logged SQL is produced. Done would require an agreed way to locate the original query from the transpiled output, but the issue does not define an implementation or acceptance criteria.

Written by the indexing model from the issue text.