bug(api): PR Merge and ResolveComments endpoints are live stubs that return 200 OK without doing anything

[fireddd]

Bug

The POST /api/v1/prs/{id}/merge and POST /api/v1/prs/{id}/resolve-comments endpoints are wired into the daemon and return successful responses, but neither endpoint actually performs any action. Merge returns {ok: true, method: "squash"} and ResolveComments returns {ok: true, resolved: 0} — the API lies about the outcome.

The frontend's PullRequestsPage has "Merge" and "Resolve" buttons wired to these endpoints. If the PR page were functional (currently blocked by #240), clicking "Merge" would show a success toast ("merged (squash)") without actually merging anything on GitHub.

Analyzed against: 96d1649 (current main)
Confidence: High — traced from controller through service to the stub implementation.

Root Cause

backend/internal/service/pr/action_service.go:37-39:

func (s *ActionService) Merge(_ context.Context, prID string) (MergeResult, error) {
    n, _ := strconv.Atoi(prID)
    return MergeResult{PRNumber: n, Method: "squash"}, nil
}

And lines 44-46:

func (s *ActionService) ResolveComments(_ context.Context, _ string, _ []string) (ResolveResult, error) {
    return ResolveResult{Resolved: 0}, nil
}

Both have TODO comments acknowledging they are stubs, but:

1. The controller (backend/internal/httpd/controllers/prs.go:26-37) doesn't guard against the stub — it has a nil-service check that returns 501, but NewActionService() returns a non-nil struct.
2. The daemon wires NewActionService() in production, so the stub is always hit.

Reproduction

# Start daemon, register a project, have a session with a PR
curl -X POST http://127.0.0.1:3001/api/v1/prs/42/merge
# Returns: {"ok":true,"pr_number":42,"method":"squash"}
# No merge actually happens on GitHub.

curl -X POST http://127.0.0.1:3001/api/v1/prs/42/resolve-comments
# Returns: {"ok":true,"resolved":0}
# No comments actually resolved.

Impact

• Data integrity: Users (or automated tooling) calling the API believe PRs are merged when they are not.
• Silent failure: No error, warning, or indication that the operation was a no-op.
• Frontend exposure: The PullRequestsPage buttons call these endpoints directly.

Suggested Fix

Either:

1. Return 501 (Not Implemented) from the stubs until the real SCM provider integration is wired, or
2. Don't wire NewActionService() into production — leave deps.PRs nil so the controller's existing nil-guard returns 501.

Option 2 is a one-line change in the daemon wiring and makes the "not implemented" state explicit.