Declare ACCESS_LOCAL_NETWORK permission so local homeservers work on Android 17

[mallafix]

Content

Declare the ACCESS_LOCAL_NETWORK permission in the matrix api library manifest (next to INTERNET).

Motivation and context

Since the targetSdk was raised to 37, Android 17's local network protections are enforced. Element X currently does not declare ACCESS_LOCAL_NETWORK, so:

• all traffic to homeservers on private addresses (192.168.x.x, 10.x.x.x, mDNS) is silently dropped — sync and push notifications stop working whenever the device is on the same LAN as a self-hosted homeserver,
• users cannot even grant the permission manually, because without the manifest declaration Android shows no toggle and appops rejects mode changes.

Declaring the permission makes the "Nearby devices" permission toggle available in the app settings, which is the minimal fix suggested in the discussion of #7077 ("devs can just add the permission to the manifest"). A follow-up could request the permission at runtime during server selection, as attempted in #7077, but this one-liner already unblocks affected self-hosters.

Fixes #7073

Tests

• Reproduced on a Pixel 9a (Android 17, v26.06.x from the store) with a self-hosted Synapse on a private address: connection attempts are rejected by the system (visible via appops get ... ACCESS_LOCAL_NETWORK showing a fresh rejectTime on every app start), no permission toggle available.
• A build with the declared permission was already tested by a user in Fix local servers not working on Android 17 #7077 (comment by @pdc1): after manually granting "Nearby devices", connecting to a local homeserver works again. This PR applies exactly that declaration.

Checklist

• Changes has been tested on an Android device or Android emulator with API 24 (see Tests above — reproduction verified on device, fixed build verified by community testing in Fix local servers not working on Android 17 #7077)
• UI change has been tested on both light and dark themes (no UI change)
• Accessibility has been taken into account. (no UI change)
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly define what will change for the user

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

[bxdxnn]

We need to ask for this permission too if the user changes or already changed his server to a local one.

[bxdxnn]

Anyway, this PR should be closed as there's an Element-submitted one there: #7165