Build first working version of IJSS for Tumblr

- Folder browser: choose an IJSS folder, create tag folders, add images
  by drag-and-drop or Open panel, with thumbnails and Finder sync
- Duplicate detection: SHA-256 fingerprints checked against a SwiftData
  (SQLite) history of posted images
- Tumblr login via OAuth 2 with a localhost redirect; tokens kept in the
  Keychain and refreshed automatically
- Posting to the Tumblr queue with folder names as tags, mixed or
  folder-by-folder order, a courtesy delay, progress, and a summary;
  posted images are archived to _Posted/<Tag>/
- Settings for the folder, Tumblr account, posting options, and clearing
  posted history (archive goes to the Trash)
- TODO.md tracking open items

Tumblr app credentials live in TumblrCredentials.plist, which is
excluded from Git.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Image Junky Sharing System.md

@@ -0,0 +1,29 @@
+# Image Junky Sharing System
+
+## Initial Development Ideas and Directions
+
+### Overview
+
+The purpose of the Image Junky Sharing System is to automate the posting of images to various online services and provide an easy way to share these images with others. Since this system is focused on the sharing of images, I'd like this to be a macOS app with a helpful graphical user interface. Initially, this app would work with Tumblr but other services can be added later after the foundational work is more-or-less complete. 
+
+### Operation and Workflow
+
+The use and operation of the app would mostly be a trigger to act upon image files in a given directory. There would be a primary directory for all services and, within that, separate directories for the various services. As an example there would be a IJSS directory, and then a directory within that called Tumblr, and within the Tumblr directory there would be other directories to handle the images. For the initial setup and testing with Tumblr, the names of the directories would correspond to a tag attached to the post. So an image in a directory called Cyberpunk would post to a Tumblr blog with Cyberpunk as the tag.
+
+My initial thought on the workflow would be something like this:
+
+1. The user opens up the app.
+2. If this is the first time the user has opened the app, they will need to connect their Tumblr blog. I'm not sure of the best way to do this but if the user could be taken to a web browser where they'd log into Tumblr and the app picked up a connection that way, that'd be good. If not, I can write documentation on how to get an API key for their Tumblr account.
+3. Once the app has successfully connected, the user can use the app to add folders to the Tumblr directory, or they can set them up manually in Finder.
+4. The user can use the app to add images to these folders, or they can set that up manually in Finder too.
+5. The user then clicks a button in the app that scans the Tumblr directory, checks for new folders and images, and begins posting the items to the Tumblr queue in the background. We could change this later on to where the items post directly to the Tumblr blog, but I think it'd be a good idea to start with the queue first. The posts should have a courtesy delay so the user doesn't get hit with a timeout or anything like that. 
+6. After the posting completes, provide a dialogue box to confirm posting or provide any failure or error notifications.
+7. The successfully posted images are removed from the posting directory and added to a database the user can use to see if they've already posted the same image before. A SQLite database should work for this.
+8. There should be some way for the user to clear the database if they want to. That should clean up all the posted images too, sending them to the Recycle Bin or deleting them outright.
+
+### Further Considerations
+
+* I know almost nothing about writing code in Xcode for macOS, so take that into consideration throughout the process.
+* I don't think I'd want to submit this to the Mac App Store, but I might like to *eventually* sign it and have it notarized by Apple so it'll run more easily for anyone who wants to download it and use it. That's not something I care to do right away, especially during the initial building and testing phase, but it'd be something to keep in mind for later.
+  * Because I might want to seek Apple notarization, the app will need to conform to standard macOS workflows, best practices, and handle things like application support and file storage in the correct manner.
+