js: Add read-only mode for comment threads

[pkvach]

Implements a client-side "read-only" mode for comment threads, controlled via the new data-isso-read-only attribute on the embed script. When enabled, the postbox and reply/edit/delete UI elements are hidden, allowing threads to be displayed without permitting new comments or edits.

• Adds "read-only" config option to client default config
• Updates comment template and embed logic to respect read-only mode
• Documents the new option in client-config docs
• Includes unit tests for read-only mode behavior

Example

• Normal mode:

• Read-only mode:

Checklist

• All new and existing tests are passing
• (If adding features:) I have added tests to cover my changes
• (If docs changes needed:) I have updated the documentation accordingly.
• I have added an entry to CHANGES.rst because this is a user-facing change or an important bugfix
• I have written proper commit message(s)
  

What changes does this Pull Request introduce?

This feature is useful for archived content, closed discussions, or when comments should be visible but not interactive. It is a UI-only restriction and does not block API calls.

Why is this necessary?

Closes: #1039

[jelmer]

Any reason this is client side only? If we stored this on the server than we could: actually enforce this, allow controlling it from e.g. the admin panel, wouldn't need JavaScript hackery to enable.

[pkvach]

Any reason this is client side only? If we stored this on the server than we could: actually enforce this, allow controlling it from e.g. the admin panel, wouldn't need JavaScript hackery to enable.

Thanks for the feedback.
You are right. Server-side enforcement gives stronger control and real locking.

I chose a small and safe change first. A client-side flag is quick to add and handles simple cases like soft close or login requirement. No backend or database changes.

A server approach needs more work, thing like:

• Add thread read and update APIs.
• Update database schema.
• Build admin UI to manage thread state.
• Make the client check thread status on each load.

I avoided this scope for now, though I agree it makes sense for a future update.

If there's interest in a server-side solution, I'd be happy to help plan or contribute to that as a follow-up.