fix: render gateway/tool/prompt/resource audit rows correctly in activity feed

[msureshkumar88]

Summary

_audit_to_activity (the renderer behind GET /api/logs/activity) only mapped two resource_type values (mcp_server, a2a_agent) that no writer in the codebase actually emits, and only mapped bare verbs (create, update, ...). Every real gateway/tool/prompt/resource/server audit row therefore fell through to the fallback and rendered mangled titles like "Gateway set gateway state", and the health-check reachability transition was indistinguishable from a normal successful write (status: "success").

• Resolve resource labels against what gateway_service.py / tool_service.py / prompt_service.py / resource_service.py / server_service.py actually write (gateway → "MCP server", server → "Virtual server", etc.), keeping the two existing keys as inert compat entries.
• Resolve composite actions (create_gateway, set_tool_state, bulk_create_tools, view_prompt_details, ...) via a token scan rather than literal string matching, so a trailing resource noun is discarded instead of repeated.
• Render set_*_state rows from their recorded new_values (enabled/reachable) instead of the literal action string, so a server going offline renders as status: "warning" / "MCP server went offline" instead of success.
• Apply the same fix to the error branch, which had the identical mangling bug on failed writes (e.g. a failed create_gateway rendered "MCP server create gateway failed").
• Prefer a writer-authored context.description (used by a few log_audit call sites) over the synthesised sentence when present.

Two changes go slightly beyond the issue's literal scope, called out here since they're the same defect class on adjacent code the issue didn't mention:

• The error-branch rewrite above.
• view_*/browse/invoke actions now resolve to status: "info" like read/execute already did, since status is now derived from the resolved verb rather than a literal string match.

Deliberately not changing any writer in gateway_service.py (the issue's suggested fix #1, flipping success=False on the offline transition): AuditTrail.success also drives SIEM export severity (_emit_audit_event_to_siem) and compliance evidence counts (collect_audit_log_evidence), so writing success=False for a health-check-driven reachability change would export every upstream outage as a severity: "HIGH" / action_taken: "denied" SIEM event and inflate failure_events in compliance reports, even though the audited write itself succeeded. Deriving status from new_values in the renderer gets the desired feed behavior without corrupting either downstream consumer.

Closes #6342

Test plan

• tests/unit/mcpgateway/routers/test_log_search_activity.py — extended TestAuditMapper, added TestStateTransitions and a hardcoded-inventory regression guard (TestRealActionInventoryRegressionGuard) covering every (resource_type, action) pair actually written by the services above
• make ruff bandit interrogate pylint on changed files
• pytest tests/unit/mcpgateway/routers/ (full directory) + targeted audit/compliance service tests