feat: add secure user resource sharing

[arnabnandy7]

Summary

• Add authenticated file and folder sharing between registered users.
• Add normalized resource-share and permission persistence models.
• Support VIEW, DOWNLOAD, and EDIT permissions.
• Add endpoints to create, list, receive, revoke, browse, view, download, and edit shares.
• Enforce ownership, recipient identity, permissions, and immediate revocation.
• Protect nested folder access against path traversal, symlink escapes, and .trash access.
• Document the sharing API and update the project structure documentation.
• Add tests for owner sharing, recipient access, denied access, permissions, nested folders, editing, traversal prevention, and revocation.

Linked issue

Closes #27

How to test

cd backend
./mvnw verify

The test suite should report:

• 202 tests run
• 0 failures
• 0 errors
• 3 skipped

The sharing endpoints can also be tested with authenticated users:

1. Create a share using POST /api/shares.
2. Sign in as the recipient and call GET /api/shares/shared-with-me.
3. Exercise the granted VIEW, DOWNLOAD, or EDIT operation.
4. Revoke the share using DELETE /api/shares/{id} as the owner.
5. Confirm that subsequent recipient access returns 404.

Notes / Risk

• Hibernate creates the new resource_shares and resource_share_permissions tables through the existing spring.jpa.hibernate.ddl-auto=update configuration.
• EDIT replaces the contents of an existing shared file. It does not create, rename, move, or delete resources.
• Moving or deleting the original resource makes its share unavailable.
• Secure Send remains a separate external-link workflow and is unaffected.
• No feature flag is required.

[DenizAltunkapan]

This is strong work. The security fundamentals are all here: path traversal is checked in depth, every resolve re-validates the real path against both the shared root and the owner root, recipient isolation goes through the repository query, permissions are enforced per operation, and revocation takes effect immediately. The tests hit exactly the properties that matter (escape attempts, cross-recipient access, edit staying inside the boundary, revocation), and the full suite passes locally at 202 tests. No conflicts, CI green.

A few things I would like addressed before approving, details inline:

1. The new share endpoints are not covered by the rate limiter. The folder download in particular streams arbitrarily large archives, which is the same resource class that is deliberately throttled elsewhere.
2. The edit write path can follow a symlink swapped in after resolution, the same TOCTOU window that #106 just closed on the read path.
3. create has no duplicate guard, so the same path can be shared to the same recipient repeatedly.

Nothing here is a design problem, the shape is right. Happy to approve once 1 and 2 are handled.

[DenizAltunkapan]

thank you