[Feature request]Serve the floating lock button through the accessibility service instead of `SYSTEM_ALERT_WINDOW

https://github.com/user-attachments/assets/1c73a4c0-bc27-4e89-a84b-86ae9f3c5098

Summary
TapLock already requires the accessibility service for screen locking, and it can host overlays too via WindowManager.LayoutParams.TYPE_ACCESSIBILITY_OVERLAY. Please migrate the Floating Lock Button from FloatingButtonService (which needs Draw-over-other-apps) to an overlay hosted by TapLockAccessibilityService.

Why

• One less permission — users no longer have to grant SYSTEM_ALERT_WINDOW (Draw over other apps). One fewer permission screen in first-run setup, one fewer sensitive permission on the Play Store listing.
• Consistency with the existing codebase — TapLockAccessibilityService already uses TYPE_ACCESSIBILITY_OVERLAY in three places (status bar overlay, edge overlays, corner overlays). The floating button is currently the only overlay that takes the SYSTEM_ALERT_WINDOW path via a separate service.
• Removes a dead foreground-service notification path — FloatingButtonService calls startForeground with a NotificationCompat.Builder, but the app never requests the Android 13+ runtime POST_NOTIFICATIONS permission anywhere (only declares it in the manifest). On Android 13+ that means the notification is silently never shown, even though the service is running. The app also doesn't surface any in-app UI hint that notifications are needed — no banner, no setup step, no toggle-time explainer — so unless the user happens to notice this on their own and manually grants POST_NOTIFICATIONS from Android's system settings, the notification stays hidden forever. Moving to an accessibility overlay drops the entire FGS + notification code path, which is currently non-functional anyway.
• Potentially usable above the lock screen — accessibility overlays can render on top of the keyguard on many devices, which TYPE_APPLICATION_OVERLAY cannot.

Implementation sketch (from a quick read of the source)

1. In TapLockAccessibilityService, add a floatingLockButton: View? field alongside the existing statusBarOverlay, leftEdgeOverlay, etc.
2. Add addFloatingLockButton() / removeFloatingLockButton() / updateFloatingLockButton(sizeDp, opacityPercent) methods mirroring the existing addStatusBarOverlay() pattern, but with:
   • LayoutParams(size, size, TYPE_ACCESSIBILITY_OVERLAY, FLAG_NOT_FOCUSABLE, PixelFormat.TRANSLUCENT)
   • gravity = Gravity.TOP or Gravity.START, saved x/y from SharedPreferences
   • The same OnTouchListener drag / edge-snap logic that lives in FloatingButtonService.addFloatingButton() today
   • The same custom-icon lookup via File(filesDir, "custom_widget_icon.png"), which works fine from the accessibility service context
3. Have the SharedPreferences change listener in the accessibility service react to floating_button_enabled, floating_button_size_dp, floating_button_opacity_percent and add / remove / update the view accordingly.
4. Delete FloatingButtonService, its <service> entry in the manifest, android.permission.SYSTEM_ALERT_WINDOW, and (since the FGS goes away) android.permission.POST_NOTIFICATIONS unless it is needed elsewhere. Remove Settings.canDrawOverlays() gates and the overlay-permission request UI in MainActivity.
5. Replace restartFloatingButtonServiceIfRunning() with a call into the accessibility service via its instance singleton, e.g. TapLockAccessibilityService.instance?.updateFloatingLockButton(...). This also solves the sibling live-preview feature request — in-place updateViewLayout / view.alpha = ... becomes trivial once the view is owned by the accessibility service.

Non-goals / caveats

• If the accessibility service is disabled the floating button won't work, but that is already true for locking itself, so it's not a new failure mode.
• Lock-screen layering can vary by OEM. If universal support isn't reliable, gating "show on lock screen" behind a toggle (default off) would be a safe compromise.
• Drag-through-touch behavior needs re-testing under TYPE_ACCESSIBILITY_OVERLAY; the existing edge / corner overlays already receive touches from the same service, so this should be a small delta.

Start with TapLockAccessibilityService, FloatingButtonService, MainActivity, and the manifest entries; compare the existing status, edge, and corner overlay methods with the floating button implementation. Verify preference changes, dragging, saved positioning, custom icons, and permission cleanup, then test the button and lock-screen behavior on supported Android versions and OEMs.