fix(bounties): centralize bounty-manage auth via Member.can_manage_bounty? (#238)

[js360000]

Summary

fix(bounties): hide manage-bounty actions from unauthorized users

Diff

 lib/algora/organizations/schemas/member.ex |  2 ++
 lib/algora_web/live/org/bounties_live.ex   | 17 +++++++++++++----
 2 files changed, 15 insertions(+), 4 deletions(-)

Claim

/claim #238

[CLAassistant]

All committers have signed the CLA.

[js360000]

For maintainer triage — quick comparison against the other open PRs against #238 (#239, #248, #253, #256, #257, #258, #260, #261):

What this PR does that the slate generally does not:

1. Adds Member.can_manage_bounty?/1 to Algora.Organizations.Member — same module as can_create_bounty? and can_create_contract?. Keeps the permission predicate in the canonical place rather than as a private helper local to bounties_live.ex. Reusable from any other module that grows manage-bounty UI later.
2. :if= on the <td> cell, not just the buttons — avoids the empty-cell layout shift you would otherwise see when the buttons disappear.
3. Also guards the edit <.drawer> — closes the residual gap where a non-owner could trigger the modal via direct phx-click injection. Matches the pattern in PR Hide bounty management actions from unauthorized users #256 and fix: hide unauthorized bounty action buttons (#238) #257.
4. Replaces the inline socket.assigns.current_user_role in [:admin, :mod] checks in both event handlers with the same predicate — single source of truth across UI + drawer + handlers. If the manage-bounty rule ever changes (e.g., add :billing role), it changes in one place.
5. Scope is tight to [UI Bug] Unauthorized 'Edit' and 'Delete' buttons visible on /bounties page #238 — does not bundle other issues (e.g., PR fix: hide Edit/Delete buttons from unauthorized users (#238) and respect email opt-out (#241) #248 also touches #241 / email opt-out).

Diff: 2 files, +15 / -4.

/claim #238