Fix the scope requests that cannot be granted and the answers that are dropped

[JingMatrix]

"system" is the framework rather than a package: it names system_server, which belongs to no package and resolves for nobody. dispatchModuleScope looked the requested package up before acting on the button, so every framework prompt died at that lookup — the approval the user had just given was answered "Package not found", the request was closed, its notification cancelled and no row written. The approve branch normalises "system" to user 0, and that line could never once have run. The framework name is now accepted without asking the package manager, and the lookup moved under "approve", the only answer that has to name something real: deny and the one-hour timeout were reported as "Package not found" as well when a package had been uninstalled while the prompt was up, which told the module the opposite of what had happened.

One request is now one prompt. IXposedService.requestScope takes a list and a single IXposedScopeCallback for it, and OnScopeEventListener is documented to run "when the request is completed", but ModuleAppService fanned the list out into one prompt per package and each was answered in its own right — a module asking for three packages made the user answer three questions and then fired that one listener three times, and a module that took the first answer as the answer acted on a third of it. NotificationManager.withdrawScopeRequests already carried a note about that cost. The whole list now goes up as one prompt whose Approve answers for all of it, deduplicated and sorted so that the same set asked twice replaces its own prompt rather than stacking a second copy of the same question, and MAX_OPEN_SCOPE_REQUESTS_PER_MODULE bounds calls rather than packages. What the user gives away in one press is what the prompt lists, so it lists all of them.

An approval was thrown away when the module's process had died. A prompt sits for an hour and the app a module runs inside can be killed at any point in it, and the receiver returned on !callbackBinder.isBinderAlive above both the claim and the cancel: the user pressed Approve, nothing was written, and the prompt stayed on screen with live buttons that did nothing for the rest of the hour. An approval is a decision about the module's scope and is recorded whether or not the module is still there to be told; deny and the timeout still take the prompt down; and the one call that can fail against a dead module is caught where it is made. setModuleScope is skipped when the approval adds no row, since it rewrites the table and enables the module on the way through.

None of this said anything anywhere. The refusal path had no log line at all, so a scope request that could never be granted left no trace in the daemon log, in logcat or on screen — which is why the framework case went unnoticed for as long as it did. The packages that did not resolve and the ones that were approved are both named now.

No new strings: xposed_module_request_scope_content takes the requested package as %3$s and accepts the list joined into it unchanged, so no translation changes.