fig8 username==password download never decodes $HEX[...] passwords despite the comment

Description

`hashview/analytics/routes.py` around line 774 (the fig8 username==password download route) has:

```python
for entry in fig8_cracked_hashes:
if entry[1] and entry[0]:
# Decode username (handle possible domain delimiters)
raw_username = entry[1]
...
# Decode password
password = entry[0]

    if username == password:
        fig8_usernames.append(username)

```

The "Decode password" comment claims decoding happens, but `password = entry[0]` is a bare assignment with no decoding — unlike the main dashboard query (same file, ~line 338) which calls `decode_hex_plain(plaintext)`.

Impact

If a recovered plaintext is stored as `$HEX[...]` (non-UTF-8 bytes), it will never equal the decoded `username`, so that username==password match is silently excluded from the fig8 export — even though the Shared Passwords / dashboard views would decode and potentially match it correctly.

Suggested fix

Decode `entry[0]` the same way the main dashboard query does (`decode_hex_plain`) before the `username == password` comparison.

Found during a repo-wide inline-comment accuracy sweep (see PR docs/inline-comment-accuracy).

Open hashview/analytics/routes.py around line 774 and compare the fig8 username==password download route with the dashboard query around line 338. Verify how decode_hex_plain(plaintext) handles $HEX[...] values, then ensure the export comparison uses the decoded password. Done means encoded passwords can participate in username==password matches consistently with the dashboard and Shared Passwords views.