Let me take a stab at an analogy :-)
Consider functions. A function has both an interface and implementation. A function may be an implementation detail of a program, or part of a library's public interface, or both. Functions may be declared in a program's 'top' namespace, or in a nested class. [1]
The declaration of a function is distinct from the implementation. Also, there are keywords you can use to control a function's visibility. For example in C++, public/private and friend. The place where a function's visibility is set is usually at the declaration, but not always -- for example, Rust lets you re-export identifiers with different visibility.
A capability is like a function. It has a declaration (the capabilities section) and a definition (the actual implementation). It may be part of the public interface (expose) and/or an implementation detail of the component (offer/use). For the purposes of this analogy, imagine a program is equivalent to a top-level class. The children are like classes in your program: they are in the end part of the same program, but there is nonetheless a definite boundary. offer is like dependency injection into those classes, via passing a particular implementation of a function. Classes, at least in some languages, can be nested, so your children can have children, etc. Finally, classes (components) can be reused between multiple programs (components).
Do a program's classes count as part of the program's interface or are they purely an implementation detail? It depends on your perspective. From the outside, the only parts that matter are those that are publicly exposed. But from the inside, a program is composed of interactions between a set of classes that define their own interface boundary through a set of functions. This observation remains true if you replace "class" with "component" and "function" with "capability".
[1] A submodule is another possible analogy, but I think a class works slightly better because it lets one draw a comparison to dependency injection.