Just so I'm clear on the situation.. you are browsing to
www.yoursite.com/resources/admin/ (with or without index.php should work)
and not ...
www.yoursite.com/resources/directory/admin/
Directives in a .htacess file affect all directories beneath them, even still
the rewrite rules from wordpress should not conflict. They basically say if you request something that isn't a file, or a directory, serve the ./index.php the ./ are the life savers.. if it were just / you would get your wordpress index.php , but ./
should serve the index.php from the requested directory.
I do find it odd that the AuthUserFile is in the directory you are trying to protect. Typically it would be outside of your browseable directories for security reasons. Also, it's usually named .htpasswd
Possibly thats what is causing the 404 ? Is there actually a passwd file in the admin directory? If so, it should contain the username and an encrypted version of the password. Ideally it would be chowned (owned) and chmod (permissions) so that only your web server can read it. Even still, since its in a browsable directory Apache will attempt to serve it if its requested, after authentication, which of course will fail.
Bottom line, the passwd file really shouldn't be there, its like locking your keys in your car. You need the keys to get to the keys so to speak.
As for me telling Fantastico what to do.. well they really just bundle Open source software for hosting providers to offer their customers. As I understand it, the hosting providers can pick and choose what apps they want bundled, and can tweak them to work under specific server conditions, although few if any actually do.
And of course .. after writing all that.. it dawns on me..
Try this..
Rename the admin directory to something.. well unique .. jellyfish for example. Rename the /jellyfish/.htaccess file to something like was.htaccess (basically removing password protection) then see if you can browse to /resources/jellyfish/index.php
If you can, then you could potentially leave it like that, but should probably take another shot at password protecting the directory. Either way, this appears to be an issue with how you have attempted to password protect the admin directory, rather than a conflict with wordpress's .htaccess .