Describe generated components by logical path, not write location (v0.1.16)

[Volv-G]

(AI-assisted)

A generated component carries annotations describing where it came from: component_yaml_path,
python_original_code_path, and the git_* set. These were derived from wherever the YAML happened to be
written, which turns an incidental choice by the caller into part of the component's identity.

Git provenance could disappear

Repository details were read from the common ancestor of the source file and the output path. That ancestor
is only inside the checkout when the output is. Generate to a directory outside the repository and the
lookup runs somewhere that is not a repository at all, so every git_* annotation is dropped and the
component records no origin whatsoever.

This needs no unusual setup to hit -- the output folder is configurable, so pointing it outside the checkout
is enough.

Bytes depended on where the file was written

Because the physical path reached the annotations, generating identical source to two different locations
produced different content, and therefore a different digest. Anything treating the digest as an identity
for the same source saw two unequal results.

What changed

Repository details are now read from the source file's own directory. The source is what the provenance is
about, and its directory is inside the checkout whenever the source is -- including when the file is reached
through a symlink from outside.

A component can also now keep its identity when written somewhere incidental. The optional
logical_output_path says where the component is to be understood to live; the bytes still go where the
caller asked. Callers that stage output in a scratch location can describe the component truthfully without
publishing a path that is meaningless to anyone else.

Compatibility

The parameter is opt-in. When it is not supplied the emitted bytes are unchanged, and two tests exist purely
to pin that: omitting it, and passing it equal to the physical path, must both be indistinguishable from the
previous behaviour.

It is also forwarded only when actually set. Several hops here are overridable, and passing a new keyword
unconditionally would break an override written against the previous signature even though that caller never
asked for the feature. A test exercises a subclass carrying the exact prior signature.

The annotation path is deliberately kept unresolved. Legacy path annotation records the name it was given, so
resolving would rewrite it whenever the output is a symlink; only the common-ancestor computation resolves.

The container image is still read back from the physical output. logical_output_path is provenance only --
reading content from a location that was never written would make a non-existent path behavioural. A caller
writing to a fresh output supplies the image, as before.

Verification

Tests drive the real generator end to end against a genuine repository, because the behaviour under test
is the path derivation; a stub cannot demonstrate it. They assert against real annotation keys and cover:
provenance surviving an output outside the checkout, the logical path being recorded instead of the physical
one, two writes to different locations producing identical bytes, no host or staging path appearing in any
annotation, a symlinked output keeping its lexical name, a symlinked source keeping its repository, and the
two compatibility cases above.

Each was confirmed to fail when the corresponding fix is reverted.