Adopt the observation funnel for Teslemetry charge port and front trunk

[Bre77]

Breaking change

Proposed change

Route the Bluetooth charge-port and front-trunk covers through a per-vehicle
ObservationFunnel from tesla-fleet-api. Only the library's
BleBroadcastPublisher is attached: streaming signals, not vehicle_data, are
the intended second source, and no stream publisher exists in the library yet,
so the funnel stays single-source BLE for now. The BLE publisher subscribes to a
broadcast only while its field is listened to. Commands still route through the
command router.

While the funnel is single-source BLE, the funnelled covers keep the
connection-generation tie of the prior local BLE path: a dropped link makes the
last broadcast stale and the cover unavailable, rather than leaving a parked,
disconnected vehicle showing its last reading indefinitely. That tie is removed
once a second source is attached and a value can outlive the BLE link.

The lock and rear trunk stay on the existing single-source BLE path: the funnel
maps only LOCKED/UNLOCKED, whereas this integration also treats
INTERNAL_LOCKED/SELECTIVE_UNLOCKED as locked/unlocked, so adopting the funnel
for the lock would drop those states in the BLE-only case.

The shared tesla-fleet-api 1.11.0 bump (teslemetry, tesla_fleet, tessie) that
ships the funnel is bundled here so this rung's tests run against the released
library; upstream it will be split into its own dependency-upgrade PR per the
one-subject rule.

This stacks on #982 (its base branch), extending the local-Bluetooth read series
with the library funnel.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to frontend pull request:
• Dependency diff (tesla-fleet-api 1.8.0 → 1.11.0): Teslemetry/python-tesla-fleet-api@v1.8.0...v1.11.0

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.