pam/go-exec: run PAM action in calling thread, not a new GLib thread

[adombeck]

kscreenlocker's PAM worker is a Qt thread (QThread). Its conversation callback (converse()) creates a nested QEventLoop to wait for the user's password via a QMetaObject::invokeMethod(..., Qt::QueuedConnection) posted by PamAuthenticator::respond().

The previous design spawned a dedicated GLib thread for every PAM action and blocked the calling thread in g_thread_join(). This caused a deadlock:

1. authd-pam invoked the D-Bus Prompt method from the GLib action thread.
2. The GLib thread called pam_prompt() → converse() → QEventLoop::exec().
3. When the user submitted a password, respond() posted promptResponseReceived via QMetaObject::invokeMethod(d, ..., Qt::QueuedConnection) targeting the Qt PAM worker thread (d's thread).
4. But the Qt worker thread was permanently blocked in g_thread_join() and could never drain its event queue, so promptResponseReceived was never emitted, QEventLoop::exec() waited forever, and the lockscreen appeared to ignore the submitted password entirely.

Fix

Call do_pam_action_thread() directly in the calling thread, removing the g_thread_new/g_thread_join indirection.

The isolated GMainContext created by do_pam_action_thread() (via g_main_context_pusher_new) is unrelated to the calling application's own GLib or Qt event loop, so there is no interference. With the GLib main loop running in the Qt PAM worker thread, pam_prompt() is also called there, the nested QEventLoop::exec() processes Qt events for that thread, and respond() → promptResponseReceived → QEventLoop::exit() works as intended.

Closes #1725
UDENG-10997

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.00%. Comparing base (a0262c9) to head (977bd59).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1726   +/-   ##
=======================================
  Coverage   88.00%   88.00%           
=======================================
  Files          96       96           
  Lines        7009     7003    -6     
  Branches      112      112           
=======================================
- Hits         6168     6163    -5     
+ Misses        785      784    -1     
  Partials       56       56           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[3v1n0]

This may be renamed now.

[3v1n0]

This is only partially true.

By pushing a new thread-default thread, then any new source that may be created in a calling application will be use that new context as their thread so not something we would like to do in general as it was explained in 13d47e2.

IMHO the way would be instead ensuring that m_prompt (pamh, style, &response, "%s", prompt) is called in an idle in the main loop (e.g the actual main thread).

[adombeck]

Copilot came up with another solution. I'm waiting for e2e-test results before requesting another review, but you can already take a look if you want.

[3v1n0]

Nah, don't think that's the way either since it assumes that there's a context.

I'd rather go with #1734