refactor(SpaceAndTime): move cmap and cmap_apply to Space/SmoothFunctions

[giuseppesorge]

This PR discharges the relocation TODO in Physlib/ClassicalMechanics/RigidBody/Basic.lean (added following the final review of #1401): the test-function constructor cmap and its evaluation lemma cmap_apply move out of the rigid-body file to a general home in SpaceAndTime/Space/.

Changes

• New file Physlib/SpaceAndTime/Space/SmoothFunctions.lean — Space.cmap, the named constructor bundling f : Space d → ℝ together with a ContDiff ℝ ⊤ f proof as an element of C^⊤⟮𝓘(ℝ, Space d), Space d; 𝓘(ℝ, ℝ), ℝ⟯, and the @[simp] evaluation lemma Space.cmap_apply. Both are the declarations previously in RigidBody/Basic.lean, unchanged except for the namespace (RigidBody → Space) and a light docstring adaptation to the new context.
• RigidBody/Basic.lean — the TODO and the two moved declarations removed; the direct import of Space.Module is replaced by the new file (which public-imports it).
• RigidBody/Basic.lean, Motion.lean, KineticEnergy.lean — each gains open Space (cmap cmap_apply), so every statement and proof body is textually unchanged. The selective open borrows exactly the two names without activating Space's scoped notations (∇, Δ, 𝔁) inside the mechanics files.
• Physlib.lean — the new file imported, in sorted position.

The whole diff is +42/−15; no statement, proof, or simp-set behaviour changes.

Why the move, and not the unbundled ρ

The TODO recorded two options: relocate cmap, or give ρ a version taking an unbundled (f, hf) pair. In the #1401 thread I suggested introducing the unbundled-ρ wrapper together with this relocation; on reflection I would rather not add it. Inside proofs the bundled form stays load-bearing — the König and parallel-axis computations work by applying map_add/map_smul/map_sum to ρ as a linear map on ContMDiffMaps — and at statement level R.ρ (cmap f hf) already is the unbundled spelling, so a dedicated def wrapping it would be a thin renaming def of the kind dropped at #1353. Happy to add the wrapper here if you still prefer having it.

Naming

SmoothFunctions.lean deliberately echoes mathlib's Geometry/Manifold/Algebra/SmoothFunctions.lean: the mathlib file carries the algebra structure on spaces of smooth maps, ours carries the Space-specific constructor into that space.

Reading order

Physlib/SpaceAndTime/Space/SmoothFunctions.lean (new file, 37 lines), then the removal hunk in RigidBody/Basic.lean; the remaining hunks are one-line open/import adjustments.

[github-actions]

Thank you for this pull-request (PR). If this is your first PR, welcome to the community!

Below is what will happen next. Please read carefully if you are not familiar with the process. You may open other PRs while this one is being reviewed, and can stack PRs on top of each other, so don't let these steps slow you down.

1. Some automated checks will be run on your PR. You can see the results of these checks at the buttom of your PR page. If any of these checks fail, you will need to fix the issues before your PR can be merged. You can learn more about these here, including how to run them locally, which is sometimes quicker than relying on the GitHub Actions. If you have never had a PR merged before, you may have to wait for a reviewer to manually start these checks (this is for security).

2. A reviewer will look at your PR and may ask you to make changes. This may happen a couple of days after you submit your PR, so you may need to be patient. But it should not be longer than that - if it is please bring it to the attention of the community on the Zulip. The level of review will depend on where your PR is submitted. If it is submitted to ./Physlib or ./QuantumInfo, the review will be more thorough than if it is submitted to ./PhyslibAlpha. You can find out more about what the review process is looking for in our review guidelines. If a reviewer adds an awaiting-author label to your PR, address the review comments, then please remove that label by adding a comment with -awaiting-author. This helps us keep track of reviews.

3. The reviewer will either approve your PR, or request more changes (in which case we return to step 2). Once your PR is approved, it will be merged by a maintainer, this should happen shortly after approval, though you may get more comments at this stage.

Tip: The easiest way to get have a fast review is to submit a PR that is small and self-contained, and has clear documentation explaining why things are the way they are in your chages.

If you have any problems or questions, please reach out to the community on the Zulip.

[jstoobysmith]

Looks sensible to me. Approved