fix(adt): treat program includes as source-bearing objects, not class includes

[enricoandreoli]

fix(adt): treat program includes as source-bearing objects, not class includes

EditSource, SyntaxCheck and the package/transport safety check all treated
any URL containing /includes/ as an ABAP class include. A program
include URL -- /sap/bc/adt/programs/includes/<NAME> -- also contains
/includes/ but behaves like a program: its source lives at <url>/source/main
and the include itself is the repository object carrying the package/transport.

Symptom

Editing any program include fails at the read step:

status 406 at /sap/bc/adt/programs/includes/<NAME>:
Accepted content types: application/vnd.sap.adt.programs.includes.v2+xml

GetSource on the same include works (it uses GetSourceURL, which already
appends /source/main for ObjectTypeInclude), so the object and backend are
healthy -- only the edit / syntax-check / package-gate paths break.

Root cause

Three spots use a naive strings.Contains(objectURL, "/includes/"):

• pkg/adt/workflows_edit.go (EditSourceWithOptions): when it thinks the
  object is a class include it skips the /source/main suffix, so it GETs the
  bare object URL with Accept: text/plain and the backend returns HTTP 406.
• pkg/adt/devtools.go (SyntaxCheck): sets the artifact URI to the bare
  object URL instead of the source location.
• pkg/adt/client.go (normalizeObjectURLForPackageCheck): strips
  everything from /includes/ to get the parent class, which collapses
  /sap/bc/adt/programs/includes/<NAME> down to /sap/bc/adt/programs, losing
  the object for the package/transport gate and for objectNameFromURL.

A program-include URL /sap/bc/adt/programs/includes/<NAME> also contains
/includes/, while a program include's source is at <url>/source/main and
the include itself is the repository object. Only class includes
(/sap/bc/adt/oo/classes/<CLASS>/includes/<type>) expose source at the bare
include URL and delegate package/transport to the parent class.

Fix

Qualify the class-include detection with the /oo/classes/ prefix in all three
spots, so program includes fall through to the normal /source/main path that
GetSourceURL / GetSource already use. Class includes are unaffected -- their
URLs contain both /oo/classes/ and /includes/.

Testing

• Reproduced on a live S/4 backend with v2.38.1: EditSource on a program
  include returns HTTP 406, while GetSource on the same include succeeds --
  because GetSource already routes through <url>/source/main and EditSource
  did not.
• After the fix, program includes take that same /source/main route for the
  read, syntax-check, update and package-gate steps; class-include handling
  (test classes etc.) is unchanged by construction (/oo/classes/ still matches).
• Builds clean (go build ./cmd/vsp, windows/arm64). End-to-end verification of
  an edit on the patched binary is still pending and not yet confirmed here.

[txape10]

Confirming this from an independent report — we hit the exact same three spots on our fork (txape10/vibing-steampunk) while adding program-include write support, filed as our own issue #133, fixed in af4c86e and 187597e:

• EditSourceWithOptions (workflows_edit.go) — isClassInclude matched on bare /includes/, so program includes skipped the /source/main suffix and got HTTP 406, same symptom you describe.
• SyntaxCheck (devtools.go) — artifact URI pointed at the bare object URL instead of /source/main for program includes.
• normalizeObjectURLForPackageCheck (client.go) — stripped /includes/NAME unconditionally, collapsing a program-include URL down to /sap/bc/adt/programs and losing the object for the package/transport gate.

Same fix shape as proposed here: scope all three checks to require /oo/classes/ before treating something as a class include, so program includes fall through to the normal source-bearing path. We can confirm this holds up in production, not just a local repro — surgical edits, syntax-check and package/transport-gate all verified against a live S/4HANA on-prem system after the fix, no regressions on class-include handling (test classes etc., which still match on /oo/classes/ + /includes/).

Noting since PR #121 (which already carries this same fix bundled with the new WriteInclude feature) is still open too — might be worth merging whichever lands first and having the other reference it, so this doesn't need re-fixing twice.