fix(app): support attachments in insecure contexts

[marcelokarval]

Issue for this PR

Closes#41706

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This fixes attachment blob-ID generation when the app is served over an insecure HTTP origin, where crypto.subtle is unavailable. It keeps the existing SHA-256 IDs when crypto.subtle is available and otherwise generates a 128-bit ID with crypto.getRandomValues. The fallback is applied to both draft storage and the active V2 attachment path, so previews can be created without relying on the secure-context-only API.

This ports the fallback accepted in #42706 to dev and adds V2-path regression coverage.

How did you verify your code works?

• bun run test:browser in packages/app — 43 passed
• bun run typecheck in packages/app
• bun run typecheck in packages/session-ui
• Firefox against a LAN HTTP origin with isSecureContext === false and no crypto.subtle: image preview appeared without a page error.

Screenshots / recordings

Manual browser verification was performed in Firefox over LAN HTTP; no screenshot or recording was captured.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential duplicate found:

• PR fix(app): fallback blob ID generation for non-secure HTTP contexts #41710: "fix(app): fallback blob ID generation for non-secure HTTP contexts"
  • fix(app): fallback blob ID generation for non-secure HTTP contexts #41710
  • This appears to address the same issue with fallback blob ID generation for insecure contexts. The current PR (44735) ports a similar fix to the dev branch and extends coverage to the V2 attachment path.

This suggests PR #41710 may be an earlier attempt on a different branch, and the current PR consolidates and improves upon that work.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍