Feature issue#111

[AnUbH75]

Summary

Implements the two behaviors requested in #111: links can now be created with no expiry ("never expires"), and an owner can permanently delete a link so it stops resolving immediately and disappears from their list for good — distinct from the existing revoke, which is left unchanged.

• expiresAt is now optional on creation. CreateSecureSendRequest drops @NotNull (keeps @Future, which already treats null as valid). SecureSendService.create() and the internal requireActive() check are null-safe: a link with no expiry is treated as always-active rather than throwing.
• lastAccessedAt — already present on the SecureSend entity and SecureSendDto but never actually written — is now set on every successful requireAccess() call (covers resolve(), listFolder(), resolveFolderArchive()), so owners can see when a link was last opened and spot stale ones, especially now that links can live indefinitely.
• New DELETE /secure-sends/{id}/permanent endpoint + SecureSendService.delete(), hard-removing the row so the token becomes unavailable immediately rather than waiting on the nightly cleanup job. Kept as a separate route/method from the existing revoke() — revoke's behavior is untouched.

Linked issue

Closes #111

How to test

Automated: SecureSendServiceTest covers null-expiry creation, null-expiry links never being treated as expired, lastAccessedAt being set on access, and delete() both removing the row and rejecting an unknown/unauthorized id.

Manual (curl):

1. Create a link with no expiresAt field in the request body → expect 200, not 400.
2. Open the returned link → expect it to resolve normally with no expiry-related error.
3. DELETE /secure-sends/{id}/permanent on it → expect 204.
4. Try opening the same token again → expect immediate 404/unavailable, not a stale success or a delay until cleanup runs.
5. Confirm existing revoke flow (DELETE /secure-sends/{id}) is unaffected — link still shows as revoked, not removed from the list.

Notes / Risk

• No migration needed — expires_at was already nullable and last_accessed_at already existed as a column, just previously unused.
• One behavior is reasoned about but not covered by an automated test: deleteExpiredRecords()'s scheduled cleanup relies on Postgres's NULL < x comparison evaluating to false/unknown, so null-expiry ("never expires") rows should be naturally skipped by deleteByExpiresAtBefore(...). This wasn't exercised via a DB-backed integration test in this PR — the existing test suite mocks the repository — so it's worth a manual check against a real Postgres instance before/after merge, or a follow-up integration test if this project adds @DataJpaTest/Testcontainers infra later.
• No new config, no new dependencies, no feature flag — "never expires" is available to all users by default; the create-form default expiry choice (frontend, separate PR) will still default to 30 days so this isn't a behavior change for existing usage patterns.
• Frontend changes (expiry dropdown with "Never," last-opened display, delete button distinct from revoke) can be checked on Feature issue#111 vault-web#324

[AnUbH75]

@DenizAltunkapan please review this PR this is only backend changes check Vault-Web/vault-web#324 for frontend changes